For me, this story starts back in 1997. I was a software developer at Microsoft, working on remote boot - making Windows 2000 boot across a network. One issue with remote boot was security, preventing a malicious user on the network from corrupting the operating system binaries as they were being downloaded.
A short digression: Microsoft normally protects against this (and the more typical case, that someone would attempt to pass off their home-built binaries as belonging to Microsoft) using code signing. Code signing uses an encryption method called
public key cryptography.
Real briefly, public key cryptography uses two different but related cryptographic keys. Either key can be used to encrypt data, and the other key is then used to decrypt it. One of the keys is made public, and one is kept as a closely guarded secret. One aspect of public key cryptography is that if person A (or company A) encrypts data with its private key, anyone can verify that the data really did come from person A just by decrypting it with A's public key.
In code signing on Windows, a company providing software uses a private key to encrypt some data that is derived from the compiled binary (it's known as a "digest", a one-way hash function of all the data in the binary that produces a much shorter, fixed length blob of data). It then packages the encrypted digest together with the binary. Any other piece of code wishing to verify the authenticity of the binary recomputes the digest itself, decrypts the digest (using the company's public key), and compares the two. If they match, then the binary is the one the original company intended.
This is the technology behind those popups asking "Do you want to run this binary signed by Company X". Code signing ensures that the binary is the one that Company X produced, not a version modified by someone else. There are ways to establish chains of trust, so a user or operating system can say "I trust any binary that was signed by someone who is trusted by someone who is trusted by someone who is trusted by VeriSign" - which is a service that VeriSign charges money for.
When the Windows 2000/XP kernel loads another operating system component, it checks that the code was signed by Microsoft, otherwise it refuses to load it. Getting back to our remote boot security issue, most of the operating system would be protected against network hacking because any modification would cause the code signing check to fail, resulting in the boot failing - a possible denial of service attack, but not nearly as bad as silently booting corrupted binaries.
Unfortunately there was a weak link in the chain. The very first piece of Microsoft code that was loaded off the network - the boot loader - was loaded by a boot ROM in the network card of the computer. That transfer itself was done using the tftp protocol, a very simple, unsecure transmission method. Thus, a clever hacker could corrupt the loader as it went by, then have his modified loader bring up a version of the kernel that did not do the code signing check, and at that point all heck could break lose on the user's machine (or, for the quick and dirty version, the corrupted loader could just format the hard drive and then stop).
This was back in the days when the "network PC," a machine that booted off the network and stored data on a server, looked like it might become a widely used type of computer. Therefore, making it boot securely was critical, and we had to figure out some way around the unsigned loader problem. The network boot ROMs were based on a standard called the
Preboot eXecution Environment, or PXE, a part of Intel's Wired for Management spec which Intel considered establishing as an RFC. We went back to Intel to discuss how to solve the security issues. The plan we came up with involved a new standard called the
Boot Integrity Specification, or BIS. BIS would be implemented in the firmware and would extend PXE, by moving the sphere of code signing down to include the initial tftp download of the loader. The boot ROM would use BIS services to check for a properly signed loader, the loader could use BIS services to check for a properly signed kernel, and then the existing code in the kernel would check for proper signing of all the binaries it downloaded over the network. BIS would also allow everyone to share the same encryption keys.
As BIS was being hashed out in 1998, the issue of securing binaries was popping up elsewhere on Microsoft's radar. Hollywood movie studios were becoming concerned about the possibility that playback of DVDs on personal computers could lead to perfect digital copies of movies. This was a year before the appearance of the DeCSS program, which broke the encryption scheme of DVDs, but already content companies felt that they had been misled on the security of DVD-ROM drives. As the movie studios put it in a filing in the lawsuit they filed about DeCSS, "the studios would not have agreed to releasing movies on DVD if it hadn't been for the DVD consortium's assurance that DVD technology implements an effective copy protection scheme."
My group working on remote boot was approached by Peter Biddle, a Microsoft employee who was the company's liaison with DVD standards bodies, and by extension kept an eye on Hollywood. Biddle explained how Hollywood expected to make money off of movies: first with theatrical releases, then with home VHS and DVD copies. Eventually a movie would be shown on television, at which point copies were expected to be rampant and no further revenue was expected. However, the period of time during which a movie was only available on VHS and DVD was considered key to making money. Movie studios were worried that easy copying of DVDs would have a serious impact on that.
To protect against this, a copy protection standard developed by Macrovision had been included in every DVD player. Extra bits were included in the DVD data, which caused the image quality to be degraded when a copy was made to a VCR (there were no Macrovision bits in broadcast television, which is one of the reasons that movie studios stopped expecting revenue once a movie had been broadcast). Hollywood was getting concerned that the access to DVD data offered by DVD-ROM drives was going to make it too easy to work around these restrictions.
When Microsoft thought of Hollywood, especially back then before the AOL - Time Warner merger, it often saw it as personified by one company: Sony. Best known for its home electronics, Sony had also become a content powerhouse after acquiring CBS Records and Columbia Pictures in the late 1980s, and was also becoming a leading personal computer vendor. It had recently introduced the Memory Stick storage media, marking it as one of the few PC vendors that innovated outside of the guidelines set by Intel and Microsoft. As a producer of both DVDs and DVD players, Sony sometimes found itself on both sides of a battle, but either part of the company was big enough to force Microsoft to pay serious attention to its plans.
It's important to understand that DVD playback on personal computers was not guaranteed to happen once DVD-ROM drives existed. It was the result of negotiation between movie studios, the DVD consortium, and the personal computer industry. In particular, it was agreed that the Macrovision bits would be preserved in the NTSC output of a laptop playing a DVD movie. As a result, DVD playback applications were given one of 408 preassigned keys allowing them to decrypt the DVD data. These keys were supposed to be carefully guarded (in fact, a DVD player eventually coughed up its key, which was one of the factors that made DeCSS possible, although it was not the only one).
As Peter Biddle explained to us, it was possible that the movie studios would completely disallow playback of newer formats - including higher-definition DVDs - on personal computers. They preferred closed hardware, such as dedicated DVD players. In fact, the upcoming Playstation 2 was really the perfect device, from Sony's point of view: it could play DVDs, yet could also be a generic computing platform, with only applications explicitly allowed by Sony able to run on it. Furthermore, there were rumors that Sony was going to make a keyboard available for the Playstation 2, and Sony was saying things such as this quote from a
1999 press release: "Sony Computer Entertainment Inc. today announced that it will establish its revolutionary computer entertainment system, PlayStation 2, as a platform for Internet-based electronic distribution of digital content in 2001."
Talk like this was enough to seriously spook Microsoft. One of the ways it combated this threat was with the Xbox, on which work began in early 1999. The Xbox could also play DVDs and run only approved binaries - approved by Microsoft.
Another way to fight Sony was to ease its security concerns, with an initiative tentatively called "Trusted Windows." The goal was to allow DVDs to be played on a Windows machine with no possibility that the bits could be copied, whether by another application running at the same time, a malicious driver, or even a custom piece of hardware that monitored the bus. Whereas code signing was designed to protect a user from an attack by code sent from another machine, Trusted Windows was designed to protect bits from an attack by a user on the same machine. Recognizing that truly dedicated DVD crackers could build specialized hardware that took the data out of the VGA output signal, the movie studios still wanted a solution that would prevent anyone from copying DVD data with off-the-shelf hardware, including the shelf of the local Radio Shack.
Since any trust in the operating system would have to begin with trust that the loader had loaded the proper kernel, Peter Biddle wanted to talk to the remote boot team about BIS and security. He invited us to a meeting that also included some folks from Microsoft Research: John DeTreville, Paul England, John Manferdelli, and Butler Lampson.
Butler Lampson was a notable in the industry, of a type Microsoft had been collecting recently. Among his other accomplishments, he was a manager at Xerox PARC in the early 1970s who proposed
funding the Alto personal workstation.
In the meeting, Lampson explained his plans for trusted DVD playback. He wanted to write a hypervisor, a meta-operating-system that would run two operating systems above it: one was plain vanilla Windows 2000, the other a smaller operating system dedicated to playing DVDs. The hypervisor would provide a complete emulation of a personal computer for Windows 2000 to run in, but would intercept all calls to the hardware to make sure they were not illegally accessing DVD bits under the control of the dedicated operating system.
We felt it was an interesting idea, but not necessarily feasible. Although Microsoft Research does some very good work, both theoretical and applied, we were wary of previous interactions between Research and product groups. These sometimes resulted in partially completed Research projects being handed over to the product group with orders to finish them, because the Research team had caught the ear of a Microsoft Vice President.
Eventually we brought in some reinforcements from the Windows 2000 kernel team and convinced Lampson that the hypervisor was not a good idea in this situation. We also gently extricated ourselves from the Trusted Windows meetings, since we had other things to worry about, mainly completing remote boot in time to ship in Windows 2000.
We never did implement BIS for remote boot, but England, DeTreville, and Lampson eventually filed a
patent for a digital rights management operating system, which incorporated some of the idea from BIS and didn't mention a hypervisor. TCPA was formed by Compaq, HP, IBM, Intel, and Microsoft in the fall of 1999, and although I was no longer involved in it, it appears that the Trusted Windows work continued inside of Microsoft Research, was eventually moved to a product development group, and has now recently made its public debut under the code name Palladium.
What does TCPA mean? At its core, it relies on code signing to ensure that "trusted" binaries are being run. Palladium builds on that; since you can now be sure that you really are running the correct Palladium binaries, you should now be able to trust Palladium to perform various other operations on your behalf. One of these is playing DVDs without leaking data, since Palladium should protect the data from malicious applications as defined in the DRM OS patent. According to a recent puff piece in Newsweek, which broke the Palladium story, Palladium also includes a series of other security-related features. However the bulk of these are not related to TCPA and instead build on Microsoft's existing security work, including its Public Key Infrastructure, the Encrypting File System, and various other features.
So which binaries will be "trusted" on a TCPA-compliant operating system that is allowed to play back DVDs? Recall that in code signing, it is the owner of the private key who gets to decide what is signed. The TCPA architecture does not specify a particular level of trust or security, just that whatever level is desired can be verified. It is possible that the same future Windows system could be booted in several different security modes corresponding to different private keys. For example, a system running on a corporate network might allow only binaries that were signed by the corporate IT department. In such an environment, a version of Linux that had been enhanced to support TCPA, built and signed by the corporate IT folks, might be a useful proposition.
The real issue at hand, however, is who is going to own the private key for a system authorized to play back DVDs. It won't be Microsoft, that's for sure. No, it will probably be a consortium of content providers, led by Sony.
What will the consortium agree to sign? Certainly not a home-built Linux application, since there are no guarantees that the application behaves. It's possible that a binary-only TCPA-aware Linux system might be signed, although it would have to enforce the DRM rules. This would break the spirit of the GPL, since it would prevent users from rebuilding the code themselves. While this is not (as some have claimed) the goal of TCPA, the GPL might become an unfortunate example of collateral damage in the battle between Microsoft and Sony.
Would the consortium agree to sign Windows 2006 (or whenever) with Palladium included? This is Microsoft's plan, of course, and Hollywood would have to balance the fear of leaking bits with the realization that being able to play DVDs on your personal computer leads to a lot of DVD sales. Microsoft would also have to get its act together: its recent Trustworthy Computing initiative, which may or may not be mere marketing, aims to reassure that remote exploits in Windows are a thing of the past. Thus it is focused on avoiding bugs in the existing architecture, as opposed to Palladium, which is a new architecture. But Trustworthy Computing may need to become reality if Palladium is to succeed: the user question "Do you want to run a binary signed by Company Y" will disappear on such a system, avoiding any potential for Outlook viruses, but if a trusted part of the operating system is discovered to have an exploitable buffer overflow, there may not be anything the TCPA hardware and Palladium software can do to stop DVD bits being copied.
On the other hand, without TCPA and Palladium, new media formats might be shut out from playback on a personal computer. Sony might be much happier if improved DVDs were only viewable on a Playstation 2, where it controls the environment. You can play DVDs on a Playstation, and you can also
run Linux on a Playstation 2 - but you can't do them at the same time. A Playstation 2 with Linux is a preview of TCPA machines to come: you can boot in a less-secure mode and get more general functionality, or you can boot into secure mode but only play DVDs and games that have been approved by Sony.
For those who feel this is all irrelevant because any new DVD formats will be quickly broken, don't get your hopes up: beyond the fact that the Digital Millennium Copyright Act makes it illegal in the United States, it may be simply be technically impossible. The ease with which the DVD CSS encryption format (and other highly-publicized recent formats) have been cracked does not mean that all encryption algorithms will yield so easily. For example, nobody has yet been able to run an Xbox application that wasn't signed by Microsoft, except by modifying the firmware - and in the future TCPA might even detect such firmware modifications and refuse to boot the operating system.
TCPA and Palladium were not created so Microsoft could damage its rivals. They were created because Microsoft and other personal computer heavyweights felt they had to. Personal computers are nice, but Sony wants them to behave like closed DVD players, becoming commodity devices for displaying Sony's content. In the forthcoming battle between technology companies and media companies for control of your entertainment dollar, TCPA and Palladium may represent the beginning of the victory of the media companies.