December 7, 2007

Forget net neutrality, how about hard drive neutrality?

You know, I never thought that I would never need to worry about hard drive neutrality. When I first heard about this I just sort of assumed it would be something vaguely sensible that people were overreacting to, but no, when you go to the site it sure seems to be true.
Due to unverifiable media license authentication, the following file types cannot be shared by different users using WD Anywhere Access.

If these file types are on a share on the WD My Book World Edition system and another user accesses the share, these file will not be displayed for sharing. Any other file types can be shared using WD Anywhere Access.

The list includes: MP3, AVI, WMA, AAC, etc. Outstanding!

Posted by ekr at 10:54 AM | Comments (3)

October 30, 2007

DVD copy protection news

Terence Spies pointed me to this item from the AACS licensing association:
AACS LA announces that it has started periodic "proactive renewals", which, primarily for software player applications, provide for periodic renewal and refreshing of AACS encryption keys by licensed manufacturers and eventual expiration of old keys by AACS LA. This helps maintain the AACS technology as a vital means of distributing valuable high definition content to consumers. Consumers should expect that updates/patches will be periodically offered by their software manufacturer in order to ensure that the players continue to function as intended. The upgrading of software is a common practice in the software industry. Pursuant to the AACS technology licenses, manufacturers of software players are required to perform such updates in a consumer-friendly fashion.
In other words, if you don't update, you won't be able to play new disks. That's not exactly a customer-friendly value proposition.

As I said earlier, this seems like an arms race that's going to be pretty hard for the manufacturers to win. It's really inconvenient for the customers to have to upgrade their players, and it's not like each new release is a simple matter of changing the key and respinning the distribution. If you want to stop the crackers from immediately extracting the key, you need to re-obfuscate the binaries so that they have to attack the binary again. The combination is not cheap for the manufacturers

In other news, Antigua-based Slysoft claims to have cracked Blu-Ray's BD+ copy protection.

Posted by ekr at 10:18 PM

September 23, 2007

How do you lock down an iPod?

Apparently the iPod SHA-1 thingamajig has been reverse engineered. As I said earlier, I'm not convinced that this actually was intended to lock down the iPod. However, it's interesting to ask how one would actually do that in a way that was harder to reverse engineer.

Two goals were ascribed to the alleged SHA-1 in the database:

If all you have is a hammer, everything looks like a nail, and if you're a COMSEC guy, problems like this bring crypto to mind. At a high level, there are two cryptographic strategies for this kind of job: encrypt the database which is then decrypted by the iPod/iTunes or apply an integrity check which is checked by the iPod/iTunes. Each of these have advantages in some contexts, but we can treat them mostly the same for the purposes of our discussion, so without loss of generality, let's talk about an integrity check.

The difficulty, as with most cryptographic contexts, is key management. We want to make sure that only legitimate copies of iTunes can produce databases that the iPod can verify, which means that iTunes has to contain a key that isn't known to third party developers. There are two options here: all copies of iTunes have the same key—this is basically the same as a fixed, secret, integrity check function or one over unknown data, i.e., the situation we have now. Any system of this type is very vulnerable to key extraction via reverse engineering. Once you have the key (or the function) you can write your own program.

The other approach is to use a separate key for each copy of iTunes. When a new iPod is attached to iTunes, it gets a copy of the key (imprinted). The most attractive mechanism here is probably to use public key cryptography and put the public key on the iPod. The key can even be signed by Apple to avoid false imprinting. Then all database updates are signed and the iPod verifies them. Of course, you can still mount a reverse engineering attack and extract the key from a single copy of iTunes, but then we're in an arms race where Apple can program new iPods to ignore that key, thus forcing the third-party software authors to constantly change keys.1

Another strategy for the attacker is not to extract a single key but rather to have the third-party software extract keys from a valid copy of iTunes, though this is obviously this is a bit inconvenient if you don't want to be involved with Apple's software at all.

If this sounds like the kind of issues you have with DRM, it is. And like DRM, the attacker has an enormous advantage as long as your system is software only and he's prepared to reverse engineer it. The situation changes a lot if you are willing to have trusted hardware (in this case on the host computer) but that would be a big change for Apple.

1. If Apple is willing to force people to register online, you can make detection and revocation of extracted keys much more efficient.

Posted by ekr at 9:17 PM

September 15, 2007

iPod/iTunes lockout, etc.?

The iPod/iPhone is obviously designed to be used with iTunes, but for a variety of reasons, some people want to use them without. A number of pieces of 3rd-party software have been developed that can talk to the iPod, copy songs to the disk, manage playlists, etc. However, the newest iPods appear to have some feature that makes this problematic:
At the very start of the database, a couple of what appear to be SHA1 hashes have been inserted which appear to lock the iTunes database to one particular iPod and prevent any modification of the database file. If you try to do either of these, the hashes will not match and the iPod will report that it contains "0 songs" when the iTunesDB would otherwise be perfectly adequate.

Can't you get around this?

Well, maybe. We really need people who are excellent at reverse engineering to help.

This is what we know so far about the start of the iTunesDB file: 

MHBD header:
0x00   4  mhbd
0x04   4  header size = 0xBC       (changed)
0x08   4  filesize
0x0C   4  unknown = 1
0x10   4  version number = 0x19    (changed)
0x14   4  child count    = 0x05    (changed)
0x18   8  itunes databaseid
0x20   2  unknown = 2
0x22   2  unknown = 0x0263         (changed, 0x0000 before)
0x24   8  ipod identification?     (changed)
0x2C   4  zero padding
0x30   2  unknown = 1
0x32  20  unknown, changing completely from itdb to itdb
0x46   2  language, seen: de, en
0x48   8  library persistent id
0x50   4  unknown, seen: 1, 5
0x54   4  unknown, seen: 0x08, 0x0D, 0x1D, 0x4D, 0x8D
0x58  20  unknown some similarities between versions
0x6C   4  timezone offset in seconds. +2*60*60 ->
          0x00001C20, -4*60*60 = 0xFFFFC7C0 (really?)
0x70  76  zero padding 0x00000000

0x32 is most likely a SHA1 hash, and 0x58 also could be.

I have no special knowledge about this particular situation, but some initial reactions follow:

Posted by ekr at 8:56 AM

May 9, 2007

DVD antitheft chips

OK, this is a clever countermeasure to DVD theft:
A chip smaller than the head of a pin is placed onto a DVD along with a thin coating that blocks a DVD player from reading critical information on the disc. At the register, the chip is activated and sends an electrical pulse through the coating, turning it clear and making the disc playable.

The radio frequency identification chip is made by NXP Semiconductors, based in the Netherlands, and the Radio Frequency Activation technology comes from Kestrel Wireless Inc., based in Emeryville.

Some obvious questions:

Not saying it's not clever, though.

Posted by ekr at 10:55 PM | Comments (6)

May 2, 2007

oh hi i fixed ur aacs

Posted by ekr at 7:03 AM

February 13, 2007

Google news cache

A bunch of Belgian publishers just won suit aginst Google News. What's going on here is kind of interesting. The newspapers allow free access to the articles for a limited time and then move them to a paid archive. Google News indexed (and cached parts of) the articles when they were free, and the cache is still accessible even after free access is ended.

Google has responded by not even indexing (let alone caching) the relevant sites That's not really a win for Google or the publishers. A better compromise would be for the cache to expire at the same time as the article went subscription only. This could be done manually on a per-site basis or with some new HTTP/HTML indicator that told Google when to remove the cache entry (as far as I know, the current HTTP caching technology doesn't really support this, though I suppose you could repeatedly probe the site to see when permission was revoked).

Posted by ekr at 11:44 PM | Comments (5)

January 27, 2007

Some additional thoughts on attacking AACS

Ed Felten and Alex Haldeman have a nice series of posts about AACS, the content control system on HD-DVD and Blu-Ray. You should really go read the posts, but here's what you need to know (somewhat simplified)

Given the title key, BackupHDDVD can decrypt the content of a disk. If you can compromise a single player and recover its key, you can use that to recover title keys which, of course you can use to decrypt disks.

Where this all went wrong with CSS was there were only a small number of keys, so once you compromised one player and published the key the game was pretty much over. But with AACS each player has a unique set of keys and the AACS includes a scheme for revoking compromised players. When a player is revoked you stop encrypting disks under its key, so it's useless for all future disks, but all disks printed before that time are (at least potentially) compromised. So, if you compromise a player and publish its key, it has a finite window of usefulness.

However, if software players are widely available, the situation is different. There's a large population of keys already available to people and all the attacker needs to do is release a piece of software which extracts the player keys from a player or patches an authorized player to either disclose title keys or the unencrypted data on a disk (as Felten observes), WinDVD already more or less is such a player, but that's presumably a somewhat temporary situation). There are of course techniques you can use to make it harder to hack software, but as far as I can tell none of them stand up to dedicated attack.

It's of course possible for the manufacturers to revoke all the players by a particular manufacturer and force them to download a new player with better tamperproofing. This has two drawbacks. First, the cost is much higher than just revoking the compromised unit because you're not just inconveniencing the attacker but everyone who happens to have a vulnerable player and most of those people are totally innocent. Second, because it's comparatively easy to break the tamperproofing the attacker can force you to incur this cost more or less whenever he wants.

It's hard to see how the studios can really solve this problem as long as purely software players are allowed.

Posted by ekr at 8:55 PM | Comments (12)

January 20, 2007

iPhone and lockin

OK, I have to admit that the Not Yet Released Device Potentially To Be Known As The iPhone (NYRDPTBKATi) looks pretty sweet, but the level of lockin significantly detracts from the overall coolness. There are actually two issues here, one bogus and one real.

DRM
The bogus one, raised by Randall Stross in the Times is the FairPlay DRM:

Here is how FairPlay works: When you buy songs at the iTunes Music Store, you can play them on one and only one line of portable player, the iPod. And when you buy an iPod, you can play copy-protected songs bought from one and only one online music store, the iTunes Music Store.

The only legal way around this built-in limitation is to strip out the copy protection by burning a CD with the tracks, then uploading the music back to the computer. If youre willing to go to that trouble, you can play the music where and how you choose the equivalent to rights that would have been granted automatically at the cash register if you had bought the same music on a CD in the first place.

This is, of course true, but sort of irrelevant. First, you're quite free to buy physical CDs and rip them yourself. iTunes will even rip them for you. At least with the iPod and presumably with the NYRDPTBKATi, there won't be any copy protection on them at all. It's true that the iPod file format obfuscates the locations of the files on the disk, but they're all there and you can get 3rd party programs which know how to read the format. The vast majority of music gets into iPods by being ripped, not downloaded.

Second, the issue isn't the iPod or NYRDPTBKATi, but rather iTMS, which imposes the DRM on the way out the door. Stross says this in the article but some misses the implication:

This claim requires willful blindness to the presence of online music stores that eschew copy protection. For example, one online store, eMusic, offers two million tracks from independent labels that represent about 30 percent of worldwide music sales.

Unlike the four major labels Universal, Warner Music Group, EMI and Sony BMG the independents provide eMusic with permission to distribute the music in plain MP3 format. There is no copy protection, no customer lock-in, no restrictions on what kind of music player or media center a customer chooses to use the MP3 standard is accommodated by all players.

In other words, it's quite possible to play non-DRMed files (what else is a podcast, after all?), it's just that (1) the music users want isn't available (2) the users don't know where to get it or (3) the UIs for getting it are too annoying. if it's really true that the major labels are willing to go non-DRM than this sounds like a great marketing opportunity for someone to make a really good non-DRM online music store. In any case, Stross's quarrel isn't with the iPod but with iTMS.

Programmability
This brings us to the real issue: programmability. According to this article the NYRDPTBKATi isn't going to be an open platform. I.e., you won't be able to load your own applications onto it. Apple has advanced two major arguments for why this is OK: protecting the network from rogue applications and protecting the stability of the device.

Here's Jobs advancing the first reason:

But its not like the walled garden has gone away. You dont want your phone to be an open platform, meaning that anyone can write applications for it and potentially gum up the provider's network, says Jobs. You need it to work when you need it to work. Cingular doesnt want to see their West Coast network go down because some application messed up.

Look, this is mostly nonsense. Yes, it's true that programmable computers can do damage to the Internet (cf. zombies, spam, DDoS, etc.) but this isn't primarily an issue of people installing the wrong third party software but rather of their machine being remotely compromised via vulnerabilities in the existing software—primarily stuff installed by the OS manufacturer. I should mention that Apple isn't giving out SDKs for the iPhone, so it's going to be harder for malware authors to program to it than (say) Windows, but that's only a temporary obstacle if it becomes an attractive attack target. There are of course ways to stop third-party malware from being loaded on at all (e.g., signed code) but the level of defense that Apple employs on the iPod doesn't suggest that they're too likely to have done anything like that here. I'd imagine they're just hiding the specs and the SDK and maybe churning the API/ABI occasionally to make it more inconvenient to write a real product.

More importantly, the danger in rogue applications isn't primarily to the access network but rather to machines other places on the Internet. It's actually very easy for Cingular to detect when a device is doing something dangerous to their network and shut it down. And to the extent to which it's not easy, Cingular has much bigger problems since they're already quite willing to sell you Windows Mobile and Palm smartphnes, which are programmable.

The second argument Apple is advancing is that letting end-users run arbitrary third-party apps will potentially destabilize the handset, contributing to a bad user experience.

We define everything that is on the phone, he said. You dont want your phone to be like a PC. The last thing you want is to have loaded three apps on your phone and then you go to make a call and it doesnt work anymore. These are more like iPods than they are like computers.

The iPhone, he insisted, would not look like the rest of the wireless industry.

These are devices that need to work, and you cant do that if you load any software on them, he said. That doesnt mean theres not going to be software to buy that you can load on them coming from us. It doesnt mean we have to write it all, but it means it has to be more of a controlled environment.

So, this is vaguely more reasonable, especially considering Apple's well-known fetish for the providing the optimal UI experience. Still, it's not particularly convincing. I've loaded several 3rd party apps on my Treo and haven't noticed it destabilizing the phone functionality. A modern O/S like OSX should be quite capable of protecting applications from each other—that kind of process isolation is one of the major functions of the OS. I haven't noticed any of the 3rd-party apps I run on my OS/X boxes being a source of massive instability.

Does it matter?
I'm probably unusual in that I'd actually like to be able to do some development on a handheld device, which would obviously be a problem if there's no SDK. That would be a big motivator for getting something based on a real operating system rather than PalmOS. But even ordinary users may find this kind of lockin inconvenient. I don't know what applications Apple intends to provide on the NYRDPTBKATi, and the truth is that they provide a pretty reasonable set on your Mac, but even so I've installed Firefox, MS Office, the Palm software suite, and Windows Media Player. Apple offers their own versions of some of this stuff and it will be interesting to see if they decide you should have to run Safari instead of Firefox or Keynote instead of PowerPoint. One of the nice things about having a general purpose computer is that you get to make these decisions for yourself rather than having Steve Jobsa make them for you.

Posted by ekr at 10:39 AM | Comments (6)