Ed's an EE, PE, and author in Poughkeepsie, NY. Contact him at [email protected] with "Dr Dobbs" in the subject to avoid spam filters.
The contractors replacing our neighbor's roof also removed the shrubs obstructing access to the front of the house. They simply wrapped a chain around each shrub's stem, attached it to their spendy pickup truck, and drove off. After they yanked out a few shrubs, we heard a mighty crash followed by a shout: "The chain broke!" Extracting the remaining plants with shovels took them considerably longer.
Apart from the dubious wisdom of using an F-350 as a tractor, a chain will invariably break at its weakest link and, once broken, isn't good for much thereafter. If you're really lucky, as the contractors evidently were, the broken link won't smash anything on its way to the horizon.
An IBM team at the Ottawa Linux Symposium presented "Trusted Computing and Linux," the Open Source approach to the Trusted Platform Module that will eventually be built into all "personal computer" systems. They sketched the infrastructure required for a complete chain of trust from the hardware to a remote server and mentioned some of the applications this technology will enable.
I broke my usual deep cover by standing up and observing that this whole Trusted Computing thing is, at a deep and fundamental level, unworkable. Although they disagreed, for obvious reasons, here's why I foresee trouble ahead.
Chain of Trust
The Trusted Platform Module sits at the core of the Trusted Computing Group's overall design. Current TPM implementations are basically 8051-class 8-bit microcontrollers with additional memory, a good random-number generator, crypto and SHA-1 hash accelerators, and specialized communication interfaces to the low-speed buses found on PC system boards, all tucked inside tamper-resistant armor.
Exact hardware and performance docs aren't available to those of us who haven't signed the usual NDAs, but the general features aren't secret. The TCG's notes on the PC BIOS implementation observes, "It must be kept in mind that the LPC bus and the TPM are comparatively slow devices...It is best to utilize these for as few measurements as possible," typically during the boot sequence.
The TPM provides a secure mechanism for computing and storing SHA-1 hashes. A "measurement" is basically an SHA-1 hash computed on a block of external storage that purportedly contains a known-good program. If a new measurement matches a hash already stored in the TPM, then it's entirely reasonable to conclude that the external program is identical to the one that produced the original hash.
To greatly oversimplify the TCG's massive documentation, the TPM acts as the initial Root of Trust for Measurement (RTM) to verify a chunk of the BIOS and the attached hardware. That verified code sets up the rest of the machinery, verifying and using additional code and hardware along the way. The BIOS eventually measures, verifies, and loads the boot code from disk, which verifies the OS loader, which verifies the OS kernel, which verifies its modules and programs, which verify the application programs you want to run. In TCG-speak, these are all Trusted Building Blocks (TBB).
Each step of this process updates a Program Configuration Register (PCR) within the TPM. Any difference along the way produces a different hash that indicates a break in the chain of trust. The system may be functional, but it cannot assert that it's running known software on known hardware.
A Trusted Software Stack (TSS) assumes control of the TPM quite early in the process to provide a more convenient and comprehensive API than just stuffing commands and data into the TPM. A program can ask the TSS to "attest" that a particular software and hardware configuration is in control of the system, which is possible because the code doing the reporting is part of the chain of trust extending back to the initial hardware reset. Unlike software-only implementations, the hardware-based TPM provides a secure repository for the fundamental secret stuff required to make that happen.
It should be obvious that for an external program to verify the configuration of a particular system, that system must be uniquely identifiable to prevent spoofing. The Endorsement Key (EK) serves that purpose: A message signed with the private half of the unique EK, which never leaves the TPM, can only be decrypted with the public half associated with that system.
Pop quiz: I can think of three separate attacks. How about you?
Attack Mode
The Trusted Computing initiative is the most spectacular example of feature creep I've ever seen. What started as straightforward corporate asset lockdown hardware has transmogrified into the preferred defense against all computing threats, including those pesky customers who copy movies and music they think they own.
A quick look through the reference links at the end of this column reveals many thoughtful discussions of the privacy implications of a system that uniquely identifies your PC, locks programs and data to it, and prevents you from deciding how you want to use your data. Being an engineering sort of bear, though, that's not what I'm concerned with. What worries me is all the ugly hardware realities swept under the rug.
The TPM was originally designed for systems kept in a reasonably secure location and, in addition to the TPM's antitampering features, the rest of the system would be hardened to match the expected threats. That assumption simply isn't true for laptops, home PCs, and other consumer hardware, which are precisely the applications touted as perfect for Trusted Computing.
A fundamental principle of cryptography is that if you give an attacker the cyphertext, crypto algorithms, and secret keys, there just aren't a whole lot of secrets left. Simple economics tells you that the rest of the system around an armored TPM cannot be hardened against intrusion. So, although "TCG requires the TPM be physically protected from tampering," I can pull your laptop apart and get access to the TPM and its surrounding circuitry.
With that access I can snoop the LPC bus (which, by definition, connects disparate chips), watch what the BIOS says to the TPM while verifying itself, and fiddle up a new BIOS that lies through its teeth. After that's done, I have complete control of the system: untrusted code running with the approval of the TPM. Any passwords involved can be snooped on the fly.
Sound far fetched? It's been done.
Existence Theorems
Last February, I mentioned Bunnie Huang's hardware bypass of the Xbox protection mechanisms. After each power-on reset, the Xbox CPU starts executing code in a 512-byte block of ROM located inside its Southbridge interface chip. That code implements a tiny virtual machine to verify and decrypt code stored in the much larger external Flash ROM memory. The Flash ROM code, decrypted into RAM, becomes the OS in charge of running the Xbox, loading programs, and so forth.
Analyzing the Southbridge code provided the information required to decrypt the Flash ROM code, despite all the security provisions. The initial extraction required a delicate hardware modification to the board to snoop data-bus transactions between the Southbridge and Northbridge chips, but a single person handled the whole process in a few days. Devising software-only attacks was then a straightforward, if tedious, task accomplished by folks around the Internet.
Microsoft responded by changing the Xbox hardware and firmware, prompting ever-more-complex assaults based on the knowledge gained from previous exploits. Xbox Version 1.6, which is more or less current in mid-2005, has fewer software errors, doesn't reveal the initial ROM contents, and now requires attaching a "modchip" to the circuitry to gain control. It's an open question whether all the software flaws are gone, but earlier Xbox units still have every error they shipped with ready for exploitation.
The benefit of cracking an Xbox seems to be limited to running a different operating system, as Xboxes are basically legacy-free PCs sold as at loss-leader prices to drive software sales. Whether the gains from cracking an Xbox balance the effort remains an open question.
Let's suppose that the BIOS code within a TPM-equipped PC can ensure that the operating system and all subsequent programs are, in fact, trusted programs. As a result, the PC has a known hardware and software configuration, without spyware, viruses, or other nasties.
Among those trusted programs will be, of course, Microsoft Windows with good, old Outlook Express and Internet Explorer. Yeah, that's the ticket—a million identical IE boxes! I can work with that.
A TPM and the TSS built atop it can ensure that any program loaded on the system has a known arrangement of bits, but that does not mean the program lacks errors. As we've seen, over and over again, Windows and OE and IE provide a vast debris field of remotely exploitable security errors.
The lesson to be learned is that a single security break can have catastrophic consequences for all systems of that type. The current hype surrounding the Trusted Computing Group's efforts ignores the effects of mass-market economics on security.
Now, what if you didn't need a hardware attack or software error to pry information out of a trusted system? That's been done, too.
Trojan Mode
Half of all PCs sold nowadays are laptops, ranging from husky desktop replacements to svelte traveling companions. Some models already sport TPM chips and within a few years the rest will, too. Unless you're in a corporation with a fairly advanced IT department, however, the TPM will arrive in an inert state with no effect on the PC's operation. Let's suppose, for the sake of argument, that it's properly activated and running as designed.
The TCG's BIOS doc states the obvious about the code that handles the TPM interface: "The Core Root of Trust for Measurement (CRTM) MUST be an immutable portion of the Host Platform's initialization code that executes upon a Host Platform Reset. [...] The trust in the Host Platform is based on this component. The trust in all measurements is based on the integrity of this component."
The TCG further states: "The manufacturer MUST control the update, modification, and maintenance...[of the BIOS boot code in the Flash ROM]."
Each BIOS version must have an associated SHA-1 hash that indicates it's been vetted by the manufacturer, so that the TPM can verify that the BIOS is trusted. The infrastructure for actually distributing BIOS hashes in a TCG-approved manner has yet to be implemented, but let's further assume that's up and running.
As nearly as I can tell, the BIOS code in all current PCs comes from the far side of the Pacific Rim. Indeed, ThinkPads in IBM livery now come from Lenovo, a company based in China, a country where the Politburo decides should happen, must happen. We trust unaudited BIOS code today, but can it be trusted as the basis of the entire TCG apparat?
Even if you can't inspect proprietary BIOS code, the TCG states that you can use the services of a trusted third party to attest to its correctness. How that would actually work in a world of relentless BIOS updates is up for grabs, as an SHA-1 hash simply means the code matches an opaque binary lump.
Microsoft, for example, has offered to release the security code at the heart of The OS Formerly Known as Palladium for third-party inspection. This is meaningless, as there's no way to analyze the security of a system based on an isolated chunk of code. Even after years of attention to security flaws, MS code continues to leak information.
Lest all this seem like racist cant, remember that none other than the Chinese Politburo recently announced a national goal to switch from Microsoft Windows to Red Flag Linux, specifically to allay concerns about hidden code. They have no reason to trust Microsoft's assurances, and I suspect that any U.S.-based TPM code would meet the same fate.
Does the notion of back-door code inserted by a national government sound far fetched? It's been done.
This Dot's on You
Color laser printers produce output so realistic that counterfeiters have given up their engraving plates and simply make money with graphics: Scan a bill or passport or ticket, print the image on decent paper stock, and laugh all the way to the bank or border or concert. Given that store clerks have accepted single-sided, black-and-white printed currency, the recognition bar may not be as high as you'd like and you can see the problem.
According to the Electronic Freedom Foundation, the United States Secret Service, the government agency responsible for tracking down counterfeiters, recognized the problem a long time ago and took action by convincing color laser printer OEMs to add watermarks. Yellow toner dot patterns apparently encrypt the printer serial number and possibly other info (including the page counter), in a nearly invisible manner on every page. This happens deep in the printer engine just before the bits stream out the laser beam to the page.
Every page you print carries a unique ID verifying that your printer produced that document and perhaps when it was printed. Even if you're churning out agitprop rather than, say, C-notes, that should give you pause.
This whole line of thought may be one of the best arguments for Free and Open Source Software I've ever seen. When you must trust the code you run, you must be able to analyze its source or pay someone else to do so, with full disclosure of the input and output. You can then compile it into an executable lump with a known pedigree. Anything else simply isn't trustworthy.
Reentry Checklist
TCG's proposals have many, many other problems. Suffice it to say that I think this genie should be stuffed firmly back in its bottle and confined to those jobs it can actually handle.
Find the Trusted Computing and Linux paper in Volume 2 of the Linux Symposium proceedings (http://www.linuxsymposium.org/2005/).
Much of the documentation on the Trusted Computing Group (https://www.trustedcomputinggroup.org/) has been updated in recent months. Pay particular attention to the document at https://www.trustedcomputinggroup.org/ downloads/whitepapers/GDV_Clarification_from_TCG_v8_English.pdf. While I've read through a good chunk of this material, I cheerfully admit that I'm far from intimate with all the gory implementation details. Actual attackers won't be so limited.
You should read Catherine Flick's thesis on "The Controversy over Trusted Computing" (http://luddite.cst.usyd.edu.au/~liedra/misc/Controversy_Over_Trusted_Computing.pdf). The March/April 2005 issue of IEEE Security and Privacy has another view on the limits of TPM technology in "Does Trusted Computing Remedy Computer Security Problems?" (http://www.computer.org/security/).
The new links to Bunnie Huang's exploits start at http://www.bunniestudios.com/. Further Xbox exploits are in Wiki format at http://www.xbox-linux.org/wiki/Main_Page/. If you want a modchip, you must do your own research. The EFF's report on printer watermarking is at http://www.eff.org/Privacy/printers/wp.php.
Bo Diddley's "Who Do You Love?" (with that famous Bo Diddley Beat) dates back to 1957, but you probably remember the George Thorogood cover. "The Chain" was Fleetwood Mac's anthem, at least toward the end of their era. Rock steady!
DDJ
