TCPA and Palladium Technical Analysis

An anonymous reader writes "After some months reading TCPA specifications and Palladium information released by Microsoft, I've finished a technical article regarding the two; the scope is technically analyzing what we know on TCPA and Palladium so we can have an objective way to judge how could it really affect us if finally done. You can read it in English or Spanish."

Comments

Conspicuously Absent

[Perdo]

From the list of supporters of DRM and Palladium is VIA, with their complete eden platform including chipset and Samual cored C3 (cyrix) processor. Even the Slashdot crew's traditional favorites, such as AMD, have signed on.

Re:Conspicuously Absent

[alecto]

Note also that Apple isn't on board. I'm as die-hard PC as they come, but am closely examining the TiBook as my next laptop because of MS's, Intel's, AMD's, and Dell's participation in these digital restrictions management shenanigans.

the risks of the "trusted" BIOS

[stanwirth]

sw: Not just overwriting your MBR -- what about the potential of the TCPA subsystem in collaboration with the TBB to block your own device drivers written for your own (experimental, read: uncertified) devices?

gg: It's a bit unclear (or maybe I didn't completely 'get' that part), how the trusted drivers would be pulled in.

It doesn't require that you know how the drivers are mapped and pulled in by the OS -- which you can set up by hand if you want to, with BSD or Linux. What concerns me is how the way TBB/PCR/TCMA is set up to enable interference with any device or driver you could ever write, and how it could be applied in an anti-competetive manner towards makers of third party peripherals.

The TBB consists of two parts: a trusted BIOS and some non-volatile data (stored in the ACPI unit) containing the fingerprints of the trusted devices, which it reads and verifies at power-up or reset.

You know how annoying it is when you've got a BIOS that thinks it knows what you want better than you do, and re-maps your /dev/hd's when you install a new IDE drive, thus invalidating your boot block, your /etc/fsck etc etc.? Think of TBB as something ten times worse, and you can't even re-flash your BIOS with something less "user-friendly/programmer-hostile."

Now, what does the TBB do with all the data it gathers (and/or incorrectly presumes) about your devices, including the checksum verifications and IPL codes? It stores them in the ACPI -- for further "system verification." Now what if the big device manufacturers (e.g. HP) set up their devices to shut themselves down, at the firmware level, when ACPI suddenly has "wrong" information about the device? (It's a power-saving feature, right? Don't you feel all warm and fuzzy.)

All the device would need to do is change its IRQ (remember these are PnP devices...) to something out-of-range. All the TBB would need to do would be to write either garbage or bad words to the ACPI any time it sees a "non-trusted" device. Thus hosing your whole system. Heck it could even send a few packets down its "trusted" network device notifying the authorities that you just installed a "non-trusted" disk drive or operating system.

Now say you were real careful and figured out a way to say, not change the MBR but trick the boot loader into to boot linux anyway, and do all your own device probing and mapping by hand, and simply bypass the ACPI where the checksums are stored. BUT! say all new monitors, printers, video cards, keyboards -- everything -- is now manufactured to check its data in ACPI. It won't matter if you've written a custom driver for it, because the device needs a valid (and fresh) key from the ACPI to continue to function.

Sure MS will probably fall flat on its face repeatedly with successive versions of the Palladium application-level API. But while laughing at the funny clown (and trying to figure out how to circumven^H^H^H^H^H^H^Htake best advantage of the Palladium API, see how badly "trusted computing" misapplied by clueless MSCEs in wanna-be corps, whose data is then an open book to...anyone and everyone) we might be diverted from the observing that TBB is meanwhile grabbing all the new motherboards, devices and busses by the short hairs. In the name of trust and energy saving, and making systems easier to "configure" or "self-configuring" to save the poor user from having to actually know anything about his or her own computer.

So this is the danger: that the overwhelming majority of new peripherals require TBB/PCR/TCMA to be running. Which would have the side effect of making it nearly impossible and highly illegal to do your own system mods, OS development, device drivers, custom devices, etc etc etc. with the new hardware.

A friend of mine's two school-age daughters use linux exclusively. When the elder started high school, she told one of her new school chums on the bus. He informed her that linux was "illegal" and that "only hackers used it." Of course she thought this was the funniest thing she'd ever heard, and the parents in our neighborhood have been laughing about it ever since. How could they possibly make an operating system illegal?

How could they, indeed.

They certainly are trying.

Re:the risks of the "trusted" BIOS

[stanwirth]

If I get what you are saying about drivers under Linux or BSD, you are suggesting that the card itself could disable itself if you don't follow the rules exactly. I don't think this is likely or even part of the TCPA spec. After all, it is designed to be disabled, although there may be a lot of things that won't function if it is disabled, but those things aren't going to work under *NIX anyway. I've never seen anything to suggest that I/O cards will do anything to support TCPA, just that drivers may be effected, or at least approved (signed) to be used.

Actually, a lot of information about each device will be recorded and checksums validated in the ACPI subsystem. And, it appears that the keys for making use of each device will be issued by a CA. Therefore, if you're building or modding boards and writing drivers for them, and the CA is simply unresponsive in issuing keys for the device you built and the driver you wrote for it , your whole system is SOL--not just that one device. If you disable the TBB & TCPA entirely, you run, as you point out, the risk of disabling all the devices which require it. Which could be the motherboard itself.

Now, about devices checking information in ACPI memory -- which will now contain not just power management data, but also TPM data -- plenty already do. How long will it be before "trusted" devices are manufactured which do, as part of their self-check on power-up, check for the TPM data of other, "non-trusted" devices prior to coming on line? True, this is not currently part of the TCPA standard, but the opportunity exists to lock *nix out of systems at this level. Given the level of FUD that will circulate about "trusted hardware" and "trusted drivers," how hard will it be for, say, HP/Compaq and INTEL to accept a massive kickback from MicroSoft in exchange for making their hardware..."trusted." i.e. unable to get a Linux driver running on it without (illegally according to DMCA) bypassing the TPM checking firmware on the device?

Sure you can bypass the whole TCPA system *now*, in the current standard. But how long will it be before it is deemed an infraction of the DMCA to do so? And how long will it be before it becomes impracticable to do so because the overwhelming majority of devices on the market require it?

So your point about having to get a certificate from a CA every time you go and play with your MBR is well-taken, and it got me thinking...that the way TCPA is set up, it makes a whole host of anti-competetive practices possible at the device firmware level -- and make the process of installing and operating linux on your home computer an even more questionable and difficult practice for the average user than it already is.

Like I said, if it were the IETF or IEEE or ISO heading this "standard" architecture for "trusted" computing, even if the committees were stacked with people from the largest companies trying to push things in a direction that would make the standard open to this kind of abuse (as they do), at least there would be half a dozen national lab/university types calling them on it (as they do).