A group at UCLA is studying how to deter DVD copying by putting RFID chips on DVDs, according to a story in RFID Journal by Mary Catherine O’Connor. (Noted by Rik Lambers at CoCo.) The article doesn’t say much about what they are planning. Reading between the lines, it looks like the group hasn’t reached the really interesting technical challenges yet.

Putting RFID on DVDs could be a terrible idea if done the wrong way. But if done correctly, it just might make sense.

One bad approach is to store part of the decryption key (needed to decrypt the data on the DVD) on an RFID chip that is attached to the DVD. The DVD player would read this partial key from the RFID and use it, along with the DVD player’s secret key, to decrypt the content. Doing this doesn’t make the content much harder to copy. And it creates several new problems: the new DVDs wouldn’t play in existing players, and the RFID might expose customers to tracking if they carry RFID-DVDs around with them.

A better approach is to use RFID to put a unique “bonus code” on each individual DVD disc. Then you can provide online “bonus features” to users who present a valid bonus code that isn’t being used elsewhere at the same time. If the bonus features are good enough, users will value getting a bonus code and so will be willing to pay more for genuine discs. And the discs will work in existing DVD players, albeit without the bonus features.

Of course, bonus codes can be copied, just like content. But if bonus codes are used to get live access to a website, and that website checks to avoid duplicate use of bonus codes, then widely copied bonus codes will be less useful, and users will have an incentive to protect their bonus codes from copying.

You don’t need RFID to bundle bonus codes with DVDs. Instead, you could put the bonus code onto the DVD with the content, but this may raise manufacturing costs, by requiring each DVD to contain some unique data, rather than being stamped out in large, identical batches. Or you could print the bonus code onto a sticker and attach the sticker to the DVD case or to the DVD itself. That’s low-tech and effective, but it requires the user to manually enter the bonus code, which is a hassle. RFID allows the DVD player to read the bonus code directly.

If you wanted, you could put the bonus code on both a sticker and an RFID. The DVD player would read the RFID if it could; otherwise the user could enter information from the sticker. Users who worried about privacy could tear off the RFID and just use the sticker. Computer-based DVD players could remember the bonus codes, so the user didn’t need the RFID or sticker anymore.

There are still privacy problems, but these could be addressed if you had a more advanced RFID chip that could execute the right cryptographic protocol. Then the chip could authenticate itself to the bonus features website, in a way that didn’t allow any individual RFID chip to be tracked from moment to moment.

This may be overkill. It’s a lot of technology to get you a relatively small benefit, compared to alternatives like using stickers, or using a disc manufacturing process that can put a small amount of unique data on each disc. But the idea of using RFID with DVDs isn’t totally crazy.

The “6th General Assembly of the Digital Media Project” recently released a set of documents “providing an Interoperable DRM Platform”. I’ve written before about the self-contradictory nature of their goal (A Perfectly Compatible Form of Incompatibility). Now we get to see how they plan to achieve the goal. And I have to say, the documents are a real piece of work. I could blog for a month just dissecting them; but I won’t subject you to that. Instead, just a small sample or two.

The documents describe a world unlike the one we actually live in. They do this, mostly, by redefining words that we all understand, creating improved versions that are distinguished typographically by capitalization. (There is a whole document devoted to definitions.) When you enter DMP-World, you give up your rights; they are replaced by Rights. And unlike ordinary rights, which you may possess simply by virtue of being a human being, Rights have to be Granted to you, and they can be Withdrawn by a Creator. In DMP-World, you can’t buy devices; all you can get are Devices. You don’t whistle a tune; you execute Functions on Governed Content. The goal of all of this is to achieve Trust: “a state where Users, Devices, or Content Data enable Users to execute Functions on Governed Content”.

All of this is done with little if any reference to copyright law. There is plenty of talk about “protection” and “intellectual property” and, of course, Rights. But not much is said about the actual scope of copyright law or its correspondence to the structure of DMP-World. Instead, DMP-World seems to redesign copyright from the ground up, replacing it with something much broader, and yet at the same time much less precise. Copyright law, for example, explains with moderate precision which types of works it covers and which it doesn’t cover. In DMP-World, the system covers Works. What is a Work? Here’s the explanation (from document 2, p. 13), which I swear I’m not making up:

The first object identified and to which IP is attributed to in the Creation Model is Work. Work refers to the fruit of an effort undertaken by an individual or group of individuals that constitutes the logical construct that persists independently of the innumerable possible physical representations of that construct. A Work on the one hand can be very concrete by being unequivocally identified through a large number of differing manifestations all of which are perceived as being of the Work yet it is also ephemeral in that proof of its existence requires the use of physically perceivable resources that are not of the Work. The Work is somewhat like an invisible hand that gives shape to a glove.

Work, it seems, it a lot like the Tao: both concrete and ephemeral, existing independently of physical manifestations, and knowable only through its tendency to give shape to the world. The Tao is even described, sometimes, using the hand/glove metaphor.

To aid your understanding, here is Lin Yutang’s translation of the first chapter of the Tao Te Ching, which does seem oddly relevant to DMP-World:

The Tao the can be told of
Is not the Absolute Tao;
The Names that can be given
Are not Absolute Names.

The Nameless is the origin of Heaven and Earth;
The Named is the Mother of All Things.

Therefore:
Oftentimes, one strips oneself of passion
In order to see the Secret of Life;
Oftentimes, one regards life with passion,
In order to see its manifest forms.

These two (the Secret and its manifestations)
Are (in their nature) the same;
They are given different names
When they become manifest.

They may both be called the Cosmic Mystery:
Reaching from the Mystery into the Deeper Mystery
Is the Gate to the Secret of All Life.

That should make things perfectly clear.

A story is circulating about a Finnish company called Viralg, which claims to have a product that “blocks out all illegal swapping of your data”. There is also a press release from Viralg.

This shows all the signs of being a scam or hoax. The company’s website offers virtually nothing beyond claims to be able to totally eradicate file swapping of targeted files. The “Company” page has no information about the company or who works for it. The “Customers” page does not mention any specific customers. The “Testimonials” page has no actual testimonials from customers or anybody else. The “Services” page refers to independent testing but gives no information about who did the testing or what specifically they found. The “Contacts” page lists only an email address. There is no description of the company’s technology, except to say that it is a “virtual algorithm”, whatever that means. Neither the website nor the Viralg press release nor any of the press coverage mentions the name of any person affiliated with Viralg. The press release uses nonsense technobabble like “super randomized corruption”.

The only real technical information available is in a patent application from Viralg, which describes standard, well-known methods for spoofing content in Kazaa and other filesharing networks. If this is the Viralg technology, it certainly doesn’t provide what the website and press release claim.

My strong suspicion is that the headline on the Slashdot story – “Finnish Firm Claims Fake P2P Hash Technology” – is correct. But it’s not the hashes that look fake, it’s the technology.

Last week, specifications were released for AACS, an encryption-based system that may be used on next-generation DVDs. You may recall that CSS, which is currently used on DVDs, is badly misdesigned, to the point that I sometimes use it in teaching as an example of how not to use crypto. It’s still a mystery how CSS was bungled so badly. But whatever went wrong last time wasn’t repeated this time – AACS seems to be very competently designed.

The design of AACS seems aimed at limiting entry to the market for next-gen DVD players. It will probably succeed at that goal. What it won’t do is prevent unauthorized filesharing of movies.

To understand why it meets one goal and not the other, let’s look more closely at how AACS manages cryptographic keys. The details are complicated, so I’ll simplify things a bit. (For full details see Chapter 3 of the AACS spec, or the description of the Subset Difference Method by Naor, Naor, and Lotspiech.) Each player device is assigned a DeviceID (which might not be unique to that device), and is given decryption keys that correspond to its DeviceID. When a disc is made, a random “disc key” is generated and the video content on the disc is encrypted under the disc key. The disc key is encrypted in a special way and is then written onto the disc.

When a player device wants to read a disc, the player first uses its own decryption keys (which, remember, are specific to the player’s DeviceID) to unlock the disc key; then it uses the disc key to unlock the content.

This scheme limits entry to the market for players, because you can’t build a player without getting a valid DeviceID and the corresponding secret keys. This allows the central licensing authority, which hands out DeviceIDs and keys, to control who can make players. But there’s another way to get that information – you could reverse-engineer another player device and extract its DeviceID and keys, and then you could make your own players, without permission from the licensing authority.

To stop this, the licensing authority will maintain a blacklist of “compromised” DeviceIDs. Newly manufactured discs will be made so that their disc keys can be unlocked only by DeviceIDs that aren’t on the blacklist. If a DeviceID is added to the blacklist today, then players with that DeviceID won’t be able to play discs that are manufactured in the future; but they will still be able to play discs manufactured in the past.

CSS used a scheme rather like this, but there were only a few distinct DeviceIDs. A large number of devices shared a DeviceID, and so blacklisting a DeviceID would have caused lots of player devices in the field to break. This made blacklisting essentially useless in CSS. AACS, by contrast, uses some fancy cryptography to increase the number of distinct DeviceIDs to about two billion (2 to the 31st power). Because of this, a DeviceID will belong to one device, or at most a few devices, making blacklisting practical.

This looks like a good plan for controlling entry to the market. Suppose I want to go into the player market, without signing a license with the licensing authority. I can reverse-engineer a few players to get their DeviceIDs and keys, and then build those into my product. The licensing authority will respond by figuring out which DeviceIDs I’m using, and revoking them. Then the players I have sold won’t be able to play new discs anymore, and customers will shun me.

This plan won’t stop filesharing, though. If somebody, somewhere makes his own player using a reverse-engineered DeviceID, and doesn’t release that player to the public, then he will be able to use it with impunity to play or rip discs. His DeviceID can only be blacklisted if the licensing authority learns what it is, and the authority can’t do that without getting a copy of the player. Even if a player is released to the public, it will still make all existing discs rippable. New discs may not be rippable, at least for a while, but we can expect new reverse-engineered DeviceIDs to pop up from time to time, with each one making all existing discs rippable. And, of course, none of this stops other means of ripping or capturing content, such as capturing the output of a player or infiltrating the production process.

Once again, DRM will limit competition without reducing infringement. Companies are welcome to try tactics like these. But why should our public policy support them?

UPDATE (11:30 AM): Eric Rescorla has two nice posts about AACS, making similar arguments.

Last week, DVD-Jon and two colleagues released PyMusique, a tool for buying songs from Apple’s iTunes Music Store (iTMS) site. This got some people upset, because songs bought with PyMusique were not encumbered by any copy protection. Now Apple, predictably, has updated iTMS to make it incompatible with PyMusique.

The standard narrative about this goes as follows: (1) DVD-Jon and friends discover a security hole in iTMS. (2) The write PyMusique, which exploits the hole to get unprotected music. (3) Apple fixes the hole and iTMS is secure once again. The standard narrative misses the point entirely.

For starters, the security mechanisms of iTMS were, and are, well designed. A system that does what iTMS does will necessarily be unable to prevent unauthorized copying of music. That’s just a fact. Apple, to its credit, didn’t overinvest in fancy anti-copying technology that would be defeated anyway. Instead, Apple built a more modest and – here’s the key point – user-friendly system that gave users freedom to make legal use of music and provided speed bumps to steer consumer behavior, but didn’t pretend to stop determined infringers. There was no point in trying to stop determined infringers, because (a) there was nothing Apple could do to stop them from ripping iTMS content, and (b) all of the songs that might be ripped from iTMS were already available on the darknet anyway.

iTMS security is a bit like the lock on your screen door: it’s not very strong, but it doesn’t have to be, because the screen door around it is inherently vulnerable anyway. Putting an expensive lock on your screen door is a waste of money because it doesn’t make you any safer. Similarly with iTMS: spending more on copy protection would have been a waste, because it wouldn’t have reduced infringement.

Rather than owning up to its savvy engineering decision not to overinvest in fruitless copy protection, Apple apparently feels compelled to pretend publicly that iTMS is “secure” in the sense that heroic effort is required to illegally redistribute content bought from iTMS. That’s obviously untrue, but Apple is unwilling to admit that in public. (The famous reality distortion field plays a role here.)

So DVD-Jon and friends came along and released software that let people buy music that wasn’t wrapped in the usual weak iTMS copy-protection mechanisms. It was always possible to get such music, by buying it via the normal methods and then stripping off the copy-protection in one of several well-known ways. So PyMusique didn’t prove anything that we didn’t already know; but it didn’t really harm Apple or anybody else either.

Still, Apple apparently wanted to maintain the pretext of iTMS security, so it updated iTMS to make it incompatible with PyMusique. It’s still possible to make a new version of PyMusique that lets people buy music from iTMS and end up with that music in uncopyprotected form; but at least Apple can give the impression of policing its security perimeter.

We haven’t seen the end of this charade. Expect more iTMS “bugs” and more “fixes” from Apple.

UPDATE (7:50 PM): As predicted, DVD-Jon has reverse-engineered Apple’s fix and says he can now reenable PyMusique. That was quick!