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

Brief summary of M$/TCPA/Palladium...

[DocSnyder]

Everyone should be able to access any data on a host - except for the user sitting in front of it.

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.

Mirror

[Anonymous Coward]

It is also here if you have a Kuro5hin account, its still in the edit queue.

I'm still wondering

[feto]

Even if the article is deep in details, it's stil unclear for me how well free/open-source OS could interoperate with such a design. Since the main issue here will probably be the patents pending, it could mean that you won't perhaps be allowed to run Linux in US or Europe, but will be in countries with more freedom (free, not always as in speach, though).

It's a standard, not an implementation

[Gerry Gleason]

He is pretty clear on MS wanting everyone to believe that TCPA == Palladium, even though it is false. It's also pretty clear that TCPA is just some very limited hardware and firmware support for a few crypto and identity functions. It is essentially OS neutral, and there is no particular security and privacy advantage for Windows no matter what the MS marketdroids say.

The interesting and worrysome parts are the potential to use Palladium for DRM, and that a lot of people could be shut out depending on the details. Most likely there will be a requirement to get a certificate from a 'participating' CA, which could be MS only, but is just as worrysome even if it isn't (say a small list approved by the MPAA and RIAA).

Note also the small comments about DOS attacks that could exploit known MS vulnerabilities to in effect disable your trusted hardware and make it hard to use your computer for just about anything. Basically, the ability of this hardware and associated software to validate your certificate to play content is pretty fragil, and it could be trashed by a virus, or many types of valid upgrades and maintanance of your computer. I think he mentions the difficulty in re-certifying your machine after a change, and that the spec doesn't really cover it. In part, it is because you have to go to TTPs (trusted third parties) to re-certify. That means you have to 'tell' MS when you make your system dual boot and write a GRUB MBR to your boot partition. Tell me that there is no potential for abuse here.

Re:It's a standard, not an implementation

[stanwirth]

That means you have to 'tell' MS when you make your system dual boot and write a GRUB MBR to your boot partition. Tell me that there is no potential for abuse here.

yup. That's the part that concerns me the most. 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? What will this enable CAs to do to smaller electronics firms? Everyone loves it when you can get, say, an optical mouse for a fraction of the cost of the M$ certified one -- and when the cheaper one works with linux. What happens when the insert your new cool device here is probed by the TBB at power-up, prior to boot, and is written off as "device not found" simply because it came from some guy's garage up in San Leandro.

Sure, it SAYS you can deactivate TBB/TCMA, but can you really? What if half your other devices require it to be activated in order to run at all? Then you'd have to grandfather in your new device as a "legacy" device, in the nomenclature of the spec itself.

So it's not just a matter of "What will DRM/Palladium/Trusted Computing do to people who write and distribute their own code? Music? Eyewitness reports of police brutality? People who seem to be having a hard time getting dist keys from the CA?" It's more like something that could kill innovative small companies in the computer industry -- you know the ones who design and build third party peripherals that compete with -- oh! Compaq, HP, IBM, Microsoft and Intel! Gee isn't that interesting that they're also the ones drafting the trusted computing standard?

You know, I'd trust "trusted computing" more if it were coming from the IEEE or IETF. Shoot, even the ISO would be welcome here. The usual suspects for drafting standards seem to be noticable by their absence on this one.

Re:It's a standard, not an implementation

[Gerry Gleason]

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?

It's a bit unclear (or maybe I didn't completely 'get' that part), how the trusted drivers would be pulled in. I think this would be 99% in the OS and not strictly part of the TCPA. Look at it this way, just what are you going to checksum to make a fingerprint that assures you that the complete OS/driver/configuration set remains unchanged? Even if you manage to do this, you have to allow for it changing, or it is hard to change anything on the system after initial configuration. All this adds up to a situation where either the system is useless, or the controls are relatively easy to circumvent (which is why they need DMCA too). Perhaps more worrysome is the fact that DMCA probably makes it illegal to do any interesting hacking or reverse engineering on a Palladium system.

I don't find TCPA to be that much of a problem in and of itself. As the article points out, the problem is that it is relatively weak at points, and the privacy issues that you have to trust to the CAs. The really nasty bits are not in the TCPA, but in how it is applied. If your goal is to beef up the security of your corporate network, you should be able to implement the CA yourself, and protect any information exchanged with the CA within your own operations, but if your need is to work with DRM media, I doubt this will be possible.

Keep in mind that Palladium is still pretty much vaporware, so we don't know how or what it will restrict. It doesn't look like anything can disuade MS from going down this path, and it is likely that the worst of our fears will be realized in the next few years. OTOH, there are bound to be problems with the implementation, and if MS burns themselves badly enough early on, they may just scrap the whole thing. I doubt that though, more likely they will stubornly keep at it until the realize that Linux has gotten ahead of them in market share, and their business is now doomed. At that point, they might even get religion and adopt Open Source as a business model.

Well I'll be blown!

[The_Guv'na]

All the M$-5ux0rZ crew are silenced! This must be a record.

Anyway, that article doesn't really tell us anything new, Micro$oft is still out to decieve us, exploit us, own us and our boxen, and take over the world and kill lin... oh crap!!

Sorry everyone.

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

[Gerry Gleason]

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.

Perhaps I injected some confusion here. By 'pulled-in' I wasn't referring to how they actually got in, but to how a Palladium system with TCPA hardware would go about validating devices and drivers. It seems like a very difficult task, and probably easily fooled by a little configuration trickery. Most driver configuration is past boot, and past bios, so it is going to be in control of the OS.

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. Also, that would be Palladium, not TCPA.

Bottom line is that according to the article, TCPA is the hardware support, and it can be disabled, so it won't be able to prevent you from running Linux. My initial comment was related to a dual boot situation, and the fact that you will be sending your IPL checksum to any CA that you need keys from. That checksum may contain sufficient latent information for them to know which boot loader you are using, although the variable partition information may mess this up enough to make it hard.

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).