Archives for 2005

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.