SYSSEC: January 2007 Archives

 

January 27, 2007

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)
  • Each player has its own key (actually set of keys, more detail here).
  • Because of the way disks are manufactured you need to have the same content on each copy, or at least to produce large batches of identical disks. So, there are a lot of movies encrypted with the same key (what's called the title key).

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.

 

January 20, 2007

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.

 

January 12, 2007

The NYT reports that a lot of users forward their corporate e-mail to external Webmail accounts:
A growing number of Internet-literate workers are forwarding their office e-mail to free Web-accessible personal accounts offered by Google, Yahoo and other companies. Their employers, who envision corporate secrets leaking through the back door of otherwise well-protected computer networks, are not pleased.

...

Corporate networks, which typically have several layers of defenses against hackers, can require special software and multiple passwords for access. Some companies use systems that give employees a security code that changes every 60 seconds; this must be read from the display screen of a small card and typed quickly.

That is too much for some employees, especially when their computers can store the passwords for their Web-based mail, allowing them to get right down to business.

I'm sure annoying authentication schemes are part of the problem—though most of the organizations I know about only require you to use your SecureID card to make a VPN connection. Not that that's not annoying enough...

In my experience, the problem isn't security but rather usability. Probably the most important factor is remote access. People want to read their e-mail on their Blackberries and the companies often haven't been that good about installing the connecting software that the employees would need to do that. So, the employees install their own connectors on their desktop. Actually, remote access in general is a problem. Webmail is super-convenient and lots of companies don't or won't offer it. But you can help yourself by just forwarding your e-mail to Gmail.

Finally, there's the usability issue. Many enterprises run Exchange and expect their employees to use the matching MS e-mail clients. The reports I've heard from people who've tried are not exactly encouraging. On the other hand, Gmail's interface is actually pretty good, and you can also use Gmail with more or less any e-mail client of your choice.

Lawyers in particular wring their hands over employees using outside e-mail services. They encourage companies to keep messages for as long as necessary and then erase them to keep them out of the reach of legal foes. Companies have no control over the life span of e-mail messages in employees Web accounts.
This is absolutely a real concern, but it's a mistake to focus on e-mail here. It's actually incredibly difficult to avoid creating archival copies of sensitive information. First, many (most?) e-mail systems make copies to the local disk to enable offline work. At this point, it tends to end up in scheduled backups. Even if you manage to suppress this by forcing everyone to work offline or implementing local expire, employees routinely save data to disk and then it gets backed up onto permanent backups. Creating access control and retention policies that stick with the data through this kind of transformation is nigh-impossible with any operating system in common use (there's a close relationship between this problem and multi-level security, by the way). And this is if you control the systems people use. It's of course massively harder when you don't.1

"If employees are just forwarding to their Web e-mail, we have no way to know what they are doing on the other end," said Joe Fantuzzi, chief executive of the information security firm Workshare. "They could do anything they want. They could be giving secrets to the K.G.B."
OK, but this doesn't make any sense. First, if your employees want to give your secrets to the KGB , what they need isn't e-mail, it's a time machine. Second, if they want to give out your secrets, they're not going to forward them to Gmail, they'll bring a flash drive to work and copy all their data onto it. It makes some sense to be concerned about inadvertant information disclosure by employees, but once you assume that you're in an adversarial relationship then you've pretty much lost.

Paul Kocher, president of the security firm Cryptography Research, said the real issue for companies was trust. "If you can't trust employees enough to use services like Gmail, they probably shouldn't be working for you," he said.

I certainly agree that if you can't trust your employees not to intentionally give out your confidential information you're in big trouble, but I don't think it's right to extend this to whether you can trust them to comply with all your corporate IT policies. Just from reading this article (and from my personal experience) it's clear that if you followed that policy you'd have to fire a lot of your employees, including good ones—people who are at least to some extent trying to act in the best interests of the company by working more efficiently.

At a higher level, the relationship between corporate IT departments and individual users is often quite adversarial. The IT departments want to standardize everyone on a particular set of software and services and the users want to use software and services of their choice. When the official IT offerings become too restrictive (in the minds of the users) they often resort to self-help, as in this case.

1. There was some interest for a while in using various kinds of cryptographic techniques for this, but it never really took off and was still hard to get right.