The Recording Industry's Failed Digital Strategy

An anonymous reader sends us a link to the Toronto Star, where Michael Geist has a terrific article on how the record labels got the Internet completely wrong. While somewhat specific to Canada, the article' arguments are more broadly applicable. The article links together the misplaced reliance on DRM and the Canadian industry's advocacy for increasing levies on blank media to demonstrate just how wrong-headed this strategy has turned out to be.

Comments

I sort of agree...

[BlurredOne]

Although I agree that both DRM and levies applied to recordable media were a bad choice to begin with, I also don't think there is a strategy yet that properly addresses the issues of digital rights. Replacing the levy on recordable media with levies on the networks supplying the media is a bad idea. Currently, in Canada, we only pay a levy on specific media, and if we are not going to make duplicates of copyrighted material, we can buy cheaper media, and bypass the levy (or just ignore the 'levy heavy' media all together). If the levy is then put onto the internet or networks, we will be forced into paying, even if we never planned on downloading copyrighted work.

That's not how TCPA works

[swillden]

Because the "ideal" trusted computing platform is built to refuse to run unsigned code period

This is a common /. meme, but it's incorrect. A TCPA TPM has no ability to control what code can or cannot run on the system. It's just a little device that sits on a bus (usually USB, though I think there may be PCI implementations) right next to all of the rest of the devices on your system. Like all of the others, a TPM is controlled by the OS and applications, not the other way around.

A TPM does four basic things:

• Hashes data fed into it, storing the result in one of a few Program Control Registers (PCRs).
• "Seals" keys to a specific PCR value, by XORing the TPM's internal master key with a PCR value and using the result to encrypt a key, which can then be stored by the OS/application software on the hard disk.
• "Attests" to a specific PCR value, by generating a digital signature of the PCR value.
• "Binds" data to a specific TPM, by encrypting it with a private key that exists only in that TPM.

An operating system can refuse to run unsigned code, but it neither needs nor really benefits from a TPM to do that. What a TPM offers (through the PCR hashing and sealing of keys) is a way to make data inaccessible unless the machine is booted with a certain set of software as well as a way for a machine to prove that it is running a certain set of software.

By itself, a TPM isn't a very useful tool for DRM, and it certainly doesn't have anything to do with making a machine not a general-purpose computer -- you can always boot a different set of software that does whatever you want, because the TPM has no way to stop you.

NGSCB/Palladium needs one more component to be able to implement really strong DRM: Hardware-supported virtualization, using Intel VT or AMD-V. The result would enable strong DRM, but only within specific virtual machines. Other virtual machines would still be fully general.

In theory, you could implement strong DRM with only a TPM and no virtualization. The process would require you to boot into a "trustworthy" OS and then use remote attestation to prove to the content provider that your machine is "trustworthy". The content provider would then give you a key which would be sealed to your trustworthy state by the TPM. This key could then be used to encrypt media which you could only play when booted into the trustworthy OS.

The problem with that is that the TPM attestation process only attests to a single hash value, meaning that all the various permutations of "trustworthy" configurations would have to be enumerated and the content provider would have to know the hashes. For several reasons, that's impractical. Workarounds based on attestation chains, where the TPM attests to PCR values at multiple points in the boot process, can be used, but those "prior" attestations are weak. There are also real problems with how to manage changes in the software stack (e.g. security patches), which would completely change the PCR values of the running system and disable access to the sealed keys unless an error-prone key migration dance was successfully performed during each update.

Not only that, such an approach would only work if the OS had no exploitable security defects that might allow a user (usually with administrative access!) to bypass DRM checks in the running system. Securing a whole, general-purpose OS against the system administrator is exceedingly difficult. Look how much trouble we have securing OSes against code downloaded from random places and run under non-admin accounts in restricted sandboxes.

The solution proposed by Microsoft in the Palladium design is to simplify the problem by having the OS boot up first (unhashed), then enable virtualization, installing a hypervisor underneath the OS and shifting the OS from running natively on the machine to running in a VM under the hypervisor.

Given that state,