IBM Trials TCPA Chip Under Linux

keihin writes "From IBM: IBM's Global Security Analysis Lab (GSAL) has done extensive analysis of the Trusted Computing Platform Alliance (TCPA) chip available on some IBM systems. We have the chip running under Linux, and have studied it extensively. In order to clarify a lot of misunderstanding about the chip, we are making available some helpful white papers and open source device drivers for Linux, so that interested people can test and use the chip in an open environment."

Comments

Why I didn't know IBM was involved

[Amsterdam Vallon]

Apparently, the TCPA folks keep the list of companies involved private which is why I had never really heard of anyone aside from IBM involved in this alliance.

However, there's a full list here.

Check out *nix.org , a dynamic, informative, and fun portal for fans of BSD, Linux, OS X, & Solaris!

just remember....

[Anonymous Coward]

Real World TCPA != DRM

Microsoft's TCPA == DRM

This is NOT about digital rights management

[metamathica]

Before people get too confused and start to complain (quite reasonably) about the RIAA, MPAA, etc: this chip is not designed to facilitate DRM. In their "why TCPA" article, they explain why it's not even particularly well suited for such systems.

Rather, it's primarily about protecting a user's private keys and facilitating (through hardware acceleration) a serious increase in the use of encryption to promote security and privacy.

Re:This is NOT about digital rights management

[curious.corn]

A HW accelerated encryption engine would give us snappy remote xsessions out of the box with ssh->ssl->kernel hw calls. I'd love this, imagine running fwbuilder on your remote fw from home. It's a must for teleworking.

Re:This is NOT about digital rights management

[Wesley Felter]

does the owner of the chip (i.e. the owner of the computer in which the chip resides) have full access to all keys embedded within the chip?

From reading the PDF, the answer is sorta. You can ask the chip to generate a new key pair, and then you can later enable/disable/delete that key pair whenever you want. But the private keys don't ever leave the chip.

Re:This is NOT about digital rights management

[manyoso]

Exactly. Without access to the actual key pair then the end user does not have control over his own computer. This facilitates DRM and not much else.

Re:This is NOT about digital rights management

[iabervon]

But it doesn't facilitate DRM at all; the private key never leaves the chip, and it isn't set until the user sets it. This makes it useless to anyone *except* the user; the MPAA doesn't have the key or even the chip. The user, at least, has the chip.

Public key cryptography works best if the user can apply the key, but cannot leak the key no matter what.

It would be rather different if the private key on the device was known to some content provider, but this setup couldn't be used for DRM even if you tried to. The closest thing would be a content provider giving you a file that only you could read; but you can still do whatever you want with it once you read it.

Re:This is NOT about digital rights management

[dusanv]

Any modern processor will deal with a well designed crypto alogrithm easily. I don't think your xssessions/teleworking are going to get noticably faster. I 'scp' large stuff over 100BT LAN all the time and my Celly 567 CPU usage is less than 2% (128 bit Blowfish). Similar results with VPN-ing. While it is true that TCPA chip can be used to speed up the encryption even further I highly doubtdon't think that was the motivation behind it.

I much much rather have TCPA then pallidium

[Billly Gates]

I view TCPA as more of a security enhancer then for drm. I trust IBM more then Microsoft to make sure Linux will run with it and it has alot of cool features.

I like the extra random number generator chip as well as the encyption chip. I can imagine it would help e-commerce greatly and can be used for programs that require random number generation. Also hardware does not need to be modified. Only the motherboard. Microsoft wants each component to trust each and have it encyrpt everything. Its scary because its so proprietary. In the Xbox even the intel pentiumIII chip encyrpts and decypts data. Infact it will not run any assembly code unsigned. Spooky.

I hope IBM horries up and convinces other OEM's to use TCPA before they decide on using pallidium. Also IBM has been selling TCPA systems for close to 2 years now. SO yes they are not a threat to freedom or a drm sollution backed by hollwood.

Re:I much much rather have TCPA then pallidium

[Arethan]

Hardware SSL encryption engines are already available as PCI expansion cards. They've been available for years. I'm not a buff on TCPA by any means, but TCPA really seems to look like just another integrated peripheral that is probably better off being an expansion card. (Kind of like integrated AGP video. Mmmmm....S3VirgE MX! lol)

Honestly, how many applications are going to use SSL encryption so often that the CPU is incapable of performing the additional grunt work? Even if every website on the Internet was SSL encrypted, your old 233Mhz Pentium still has a shitload of spare cycles to throw at en/decoding the data streams. The only systems that really benefit from the hardware encoder/decoder are secure webservers. The ability to offload that little bit of processing gives them the ability to handle a few more requests per second.

As for the secure storage of SSL keys. I can't wait until my mainboard dies, and I can't get my keys off the damn chip. I suppose you could buy another identical board and attempt to swap the chips, but I'll warn you right now that surface mount soldering by hand is an extreme bitch.

And it really isn't like you're going to get that much extra security out of the deal. So your keys aren't on the harddrive anymore. So now people can't get your keys by stealing your tape backups anymore. What happens when you have a fire? Hope you have a really good memory and a nice hex editor to retype the keys with. And what is to stop any processes at all from reading all the keys out and emailing them to a hotmail account? Only allow priviledged processes to access the chip? How do you define with process is priviledged?

Sorry, but I'll stick to the expansion cards. At least if something bad happens I can replace those relatively cheaply and easily.

At least read some of it before commenting...

[26199]

The white paper explains why it would be easy to circumvent this chip if you have physical access to it.

DRM it is not.

They've released full GPL source code.

Looks like it could be useful.../p>

Whitepaper biased

[Anonymous Coward]

It's unfortionate to see White Papers, which in my opinion, should present fact, be so biased. If you read the author's section on DRM in the TCPA rebuttal you get a feeling like you're reading a post on slashdot.

Comments like: "I have no problem with people arguing against DRM; I agree completely." should not be there. It's ok to agree/disagree with DRM, but not in public documents with your employers name on them.

Just my $.02 CAN.

Jason

Passing the blame.

[Phoenix823]

While perhaps technically inaccurate as to the difference between TCPA and Palladium, I think the spirit of the attacks made against the platform are valid. While yes, perhaps TCPA doesn't directly enable all the horrible things we Slashbots complain about, but the paper is just passing the blame.

IBM says "this has nothing to do with DRM. In fact, it doesn't protect it from owner-tampering so it's not any great DRM replacement." Of course, they don't mention that it's more than likely that in the near future, a version of Windows will take advantage of it. Maybe the OS will encode all recorded music with your public key so it's unplayable on any other machine? Who knows, the possibilites really are limitless.

I wonder how many TCPA computers will be running Windows with Palladium enabled. Neither paper seemed to be catering to a very tech-head audience, so why make needlessly complicated distinctions between TCPA, Palladium, databuses, etc?

Re:Passing the blame.

[Billly Gates]

Well the good news is that you can turn it off. The bad news is that the email from grandma may require palladium and not TCPA. TCPA is different then Palladium and has been in use since 99 on almost all IBM systems. Ask any ThinkPad owner. Also there are only 2 chips in the motherboard that make up the TCPA as well as a special bios.

In palladium each component must be certified and it uses a trust relationship to prevent tampering. To me palladium sounds like a way for Microsoft to make sure you can not upgrade more then afew components at a time without paying the piper but who knows. It sounds more stict and anti-user. Also rumours have it that Bill Gates wants to use palladium as a way to stomp out piracy in asia and they also view OOS as the bigggest competitor since os/2. Scary.

TCPA was formed to secure and enhance e-commerce as well as secure corporate desktops. In this day and age the security is greatly needed.

If hollywood wines and complains and the hollings bill passes, I prefer TCPA anyday and its a more open and industry standard solution. Linux will be supported since any thid party can sign it and no company is the "official" gatekeeper. Think SSL. The gatekeeper argument is the scariest and as long as it stays open then its not a problem. IBM has invested billions in Linux and wants it to susceed.

what about the OS securing features

[samantha]

As far as I can tell, it wouldn't be difficult to build systems running say, Win XP, with the hashes marking the trusted OS keeping any other OS from being loaded and successfully booted on the machine. Of course this is more like with a Palladium based machine. But this spec also allows it from what I got out of the paper.

Also, regardless of the author's opinion, a chip that enables DRM even sub-optimally is not the friend of the people.

Some nice quotes from the misinfo rebuttal

[pridkett]

For those of you who didn't read the stuff:

The bottom line is that TCPA and Palladium are two different projects. The TCPA hardware provides only a subset of the full Palladium functionality, which includes significant additional hardware and software elements. Only TCPA already has a freely downloadable detailed specification, and a tested port of all driver and library level software to Linux.

Don't get completely up in arms about this is what is trying to say. Then he has an even better quote later:

My personal opinion (not speaking for IBM) is that DRM is stupid, because it can never be effective[6,7], and it takes away existing rights of the consumer. But this is not the place for that debate. To condemn TCPA for the ability to run a bad application is absurd. This argument is exactly like the arguments of governments in their attempts to ban encryption, under the rationale that encryption can be used by terrorists to hide their messages.

Ahh...it's great to take stuff outta context.

Quick notes for spastic no-read replies:

[moogla]

1) IBM doesn't care about DRM. In fact, this chip is completely unsuitable for DRM (and the white paper author was kind enough to explain why... protects you from SOFTWARE attacks, not hardware.)

2) The specs are open. There is a gratis GPLd demonstration driver/API for linux.

3) (My impression) is that it helps solve certain security chicken and egg problemswhen you want to do things like mount an encrypted hard disk, but not want to store the decryption key in memory.

4) Primary advertised use: for signing and verifying your OWN code, i.e. to protect yourself from root kits.

Big claims...

[Goonie]

From reading their discussion paper, they claim TCPA can be used to (amongst other things):

• Generate a public/private key pair, the private part never leaves the TCPA chip.. That's kinda nifty, because even if the bad guys get a root compromise on your system they still can't get your private key. They could however use the TCPA system to decrypt messages USING your private key though, until the root compromise was discovered and removed. So, kinda nice, but not a panacea.
  
• Put critical data (eg the encryption key for an encrypted FS) in a secure register that can't be accessed if "the operating system environment" is changed. I would need to spend some time reading the TCPA specification to understand exactly how they intend for this to work, but I'm dubious about this example. Once this data gets out of the secure environment, it's vulnerable to compromise, so in this case I don't see what this adds over keeping the key in the user's head, for instance.
  

Additionally, I'd be interested to see how the system copes with software upgrades. It seems like an impossible task to build a system that allows easy software installation but isn't itself vulnerable to accepting a trojan - and because the system's hardware the protocol can't be easily modified to deal with flaws.

Presumably IBM has smart people who've considered this and think their solution is workable. In my copious free time maybe I'll download the spec and have a look... :)

Moronic knee-jerk reactions...

[Theovon]

Reading the IBM paper and some of the propoganda against TCPA, I have to express my distaste for those who constantly insist on crying "boycott this", "ban that" whenever something like this is developed without bothering to actually find out what it is. First, there was DRM, which is bad, then Microsoft comes out with Palladium, and all these idiots ASSUME that it's Microsoft rolling over for Hollywood. Well, I don't like Microsoft anymore than the next geek, but Microsoft isn't about to do anything they think would cost them money, and so it appears that Palladium isn't any more of a threat to our freedom than TCPA. Besides, MS just joined an anti-DRM coalition! SO... then we learn about TCPA, and OF COURSE, people immediately begin yapping about how it's another form of DRM and making up "facts" out of whole cloth and doing nothing but confusing the issue.

Activism is a good thing when it HELPS something, but everything is clouded for no good end when people leap to totally uninformed conclusions and then make every activist look like morons along with them. The anti-TCPA people should be ASHAMED of themselves.

Re:Moronic knee-jerk reactions...

[geekoid]

"MS just joined an anti-DRM coalition!"

Only because the the way DRM is being pushed, puts them out of control. MS wants you to have a house full of computers, all of which are connected to them. It is part of the 1000 year vision.
In 95 or 96 Bill Gates was at a smartcard conference.
At that time he said he wanted a smart card reader in every computer, and for it to be verified by MS before allowing any purchases. The only problem was there was no was to verify what system is was coming from.
Sure, on paper, TCPA is a good thing, with many practical uses. However, look at how any industry that makes money doing something digital(whether it is CDs or OS) blames all there woes on piracy.
That is the leverage/excuse MS will use to "embrace and extend" the TCPA technology.
MS is not rolling over for hollywood, and nevcer will. What they will do is utilize Palladium, with TCPA, so they can charge the entertainment companies for a "verification" service. Of course any OS they can't "trust" will be excluded.
The question is, will the backlash be great enough for it to fail? If it was put into place right now, the backlash would be minimal, because the number of non MS desktops user is very small, and they don't make much money from those users anyways.

It is the mission of almost every corporation to make as much of a market as possible.

You should be ASHAMED for not learning from history, and not using you imagination on how this can be used against you.

TCPA is to DRM as Bullets are to a Gun, neccessary.

Re:Great news

[sfe_software]

Good to see??? umm... I hope your joking, cause otherwise, you have NO FUCKING CLUE WHAT YOU'RE TALKING ABOUT!!!

I'm honestly not sure what you mean here, but from your .sig link to notcpa.org, I guess you're not a supporter of the TCPA.

So tell me -- did you read the whitepapers mentioned in the article? Or are you simply going by the FUD presented at notcpa.org?

Seriously, whether you are for or against the TCPA, read the white-papers IBM put together. Note that it has nothing to do with DRM or Palladium, and the author of one of the papers says "DRM is stupid, but that's another paper".

Or go read the specifications yourself.

In short:

1) The TCPA is NOT Palladium
2) It does NOT protect against physical tampering (thus not being well suited for DRM usage)
3) It doesn't use any cert authority or "code signing" or anything like that. This again is not Palladium, and this is not the XBox.

It really is about helping to protect you against crackers or viruses/worms from obtaining your private keys (be it SSH, SSL, PGP, or whatever future application comes up).

And IMO it is good to see IBM on-board. They've already written GPL drivers for Linux, and are showing massive support from the very beginning -- something you rarely see with *any* new specification or proposed standards. Any Linux user should be glad IBM is on-board as well.

People please remember

[codepunk]

Microsoft to Dell: could you please ship our new paladium board in your computers.

Dell to Microsoft: Fuck off if word gets out that you cannot copy stuff on one of our machines we are certainly ruined.

Microsoft to Dell: Do it or else

Dell to Microsoft: Fuck you we are shipping Lindows

Wake up!

[Kevitt]

Have all of you gone insane?
TCPA...DRM...Palladium? What the hell's the difference in the end? I cannot believe that anyone is supporting ANYTHING even remotely resembling any type of DRM or trusted computing scheme.

Have we really lost so much focus that we are willing to give up our RIGHT to do whatever we please with the data that resides on our drives? Even if it's a small concession, the road to hell is walked one small step at a time.

Hardware protection of private keys

[QuantumG]

I've always been amused at the claims of how hardware can solve security problems. The suggestion of how to protect authentication using TCPA and, indeed, all other "smartcard" based solutions, is to make sure the private key never leaves the hardware. The idea being that the attacker cannot access a server from any other machine than the one containing the hardware. This is clearly not the case. Suppose you use SSH to access your server at work and, for added protection, you use TCPA to keep your private key. An attacker hacks your client attempting to access to the server at work. All he/she has to do is use your hardware to access the server. At this point the attacker can bypass the authentication by:

1. Installing a new key;
   
2. Installing a back door; or just
   
3. Taking what they want
   

A proposed solution to this problem is to encode the private key with a passphrase. Unfortunately, almost all the systems that do this use software to read and check the passphrase, making it simple to intercept.

Re:Hardware protection of private keys

[JordoCrouse]

All he/she has to do is use your hardware to access the server.

For most people, all he/she has to do right now is use your software. For all except for the very paranoid, keychains are hanging out there right on the hard drive, open to every Tom, Dick and Harry that bothers to walk by.

But even then, what does access to the private key really give you? SSH does nothing as far as actually authenticating you on the server - it only encrypts the data as it passes to and from the system. The remote server does the actual challenge / response. Somebody might be able to pretend that they are you, but without the password, they are up the proverbial creek.

Really, this chip is no less resistant to physical acess than the software solution. Computer security isn't just about a password. You wouldn't leave your server room unlocked would you? Why would you treat your workstation any differently?

TCPA only a single component of Palladium

[Powercntrl]

By itself, a security coprocessor is no different than using the PIII's serial number to create a unique hash and processing encryption on the main CPU.

Imagine you already have this TCPA processor on your board. You download the newest RIAA-approved secure media player and start downloading tons of songs. The media player wants to use your TCPA processor to encrypt the songs while you're downloading them so only your PC can play them. Evil, yes, but it can be done TODAY on a PC without a dedicated TCPA processor.

The application is happily encrypting its audio, however, in the background you're running an application that acts as a virtual soundcard and you're capturing open, unencrypted audio and saving THAT to your hard drive as well. So much for TCPA.

This is where Palladium comes in, it would not allow you to run a virtual sound card driver. Palladium is about a trusted secure enviorment, which requires the cooperation of the BIOS (ensure the OS that is about to be booted is trusted, and possibly in the future BLOCK booting of non-trusted OSes entirely), the OS, the main processor (for secure memory protection) and the video and sound cards. It is highly likely implementations of Palladium systems will not even HAVE a dedicated TCPA chip that can be easily attacked and disabled - the features will be built right into the main CPU.

You dont make sense

[QuantumG]

Let's stop thinking about Windows for a second, seeing as IBM has presented a bunch of GPL drivers for Linux. On my Linux box, I choose how to use this chip. Instead of running ssh-keygen I run a client program and tell the chip to generate my keys. Then when I want something encrypted with the private key that it has generated I just send it the data and it encrypts it for me. I'm completely in control.

The most obvious use is to authorize my connection to a remote server. If the private key is safely locked away on the chip then I can be assured that only my machine can connect to the remote server with that identity.

Another use would be to sign emails. Again, I can be assured that any email that is signed with a key that is safely locked on the chip could only have been signed by someone using my machine.

In fact, I'm hard pressed to come up with a way that this chip could be used to do DRM under Linux. Can you?

Re:You dont make sense

[jbolden]

In fact, I'm hard pressed to come up with a way that this chip could be used to do DRM under Linux. Can you?

Yes you would do it exactly the same way you do it under windows.

Sony has a nub (say a version of the Linux kernel) which they trust. You can download these kernels from Sony and full compliance with the GPL Sony release full source. Any change to the kernel changes the signature of the nub and thus makes it untrusted by Sony. So in other words Sony can now sign off on your OS kernel.

Because of the TCPA public key they can also lock stuff to your machine. And they can combine these, that is they can give you content which can only be used on your machine running and only when running particular kernel.

But they can go even further than this. The kernel supports trust and they can release a media player which will ask the kernel if the application is running inside a virtual environment or directly against the trusted kernel. Since the kernel supports trust it tells the truth, since the you can't change the kernel without changing the signature on the nub you can't make a kernel that lies.

That's DRM.
And everything I've mentioned can be 100% open source GPL and it will work exactly the same.

Question

[PetWolverine]

Okay, so TCPA is not evil, as I had been led to believe. I have a nagging question about it, though, that I need answered before I consider it a Good Thing.

Let's say I'm sitting and twiddling my thumbs, or serving rather a lot of MP3's to the Internet at large, or something, and my computer crashes. Uh-oh, the hard drive can't be read. Looks like I need to boot from another drive to fix it. Trouble is, when I try to do so, TCPA interrupts and tells me I'm trying to boot from a different system, which isn't allowed. How do I repair my drive?

Of course, as a Mac user, I guess I don't have to worry about this much anyway (Apple still hasn't signed up for TCPA, right?). Besides, maybe in the Wintel/*nix-other-than-OS-X world I know so little about, there's a simple way to overcome this. But wouldn't a simple way to overcome it involve using software to make the switch? It's either that or jumpers on the motherboard, right? So the question stands.

Somebody fill the void in my brain! I long to know!

Re:normal users of Linux?

[manyoso]

From an interview with Jim Ward of IBM (one of the authors of the TCPA spec)

"The TCPA specifications center on two main areas: trusted reporting and public key infrastructure (PKI). The TCPA reporting guidelines create profiles of a machine's security settings as the machine boots. Ward says content providers such as Bloomberg or Hoover's may take advantage of this feature to ensure users do not redistribute content."

I have read enough about TCPA and Palladium to know that these are DRM enabling technologies. I also know that members of the TCPA and BSA are very interested in providing DRM. This is obvious and if you'd read around you would see the same thing.

Re:Linux vs. Linux users

[Arandir]

That is it was designed to encourage the free sharing of information in a communal fashion.

Thomas Jefferson (paraphrased): "If men were angels there would be no need for government, but since they aren't, there is."

It would be really nice if people didn't steal. But they do. Therefore I fully support the right of anyone to aquire and use the strongest locks possible. The only way I know of preventing people from stealing my financial, medical and personal information from my computer is to lock it up. If TCPA make this easy to do without giving up rights to third parties, then the prudent will use it.

More misdirections

[NigelJohnstone]

Here's another misdirection, again he is rebutting a valid comment.

-------
The comment he is rebutting:

"You might prefer not to have to worry about viruses, but neither TCPA nor
Palladium will fix that: viruses exploit the way software applications (such as
Microsoft Office and Outlook) use scripting."

His rebuttal:

While TCPA cannot prevent stupidity
in software applications, it definitely can control the resulting damage. In particular,
no virus can steal a TCPA protected private key.
How can it, if the private key is
generated in the chip, stored on the chip, and never leaves the chip?

Again the comment he is rebutting:

" Seen in these terms, TCPA and Palladium do not so much provide security for the
user as for the PC vendor, the software supplier, and the content industry. They do
not add value for the user, but destroy it."

And his rebuttal of this:

Personally, I find the ability to protect my
private keys, and to protect my encrypted data very important and very valuable.

-------

The misdirection here is in the last paragraph. The keys he is talking about are not *your* keys. They are not specific to *you* you do not carry them around from PC to PC and you do not have access to them.
Your keys (things like your passwords and PGP keyring files) can be stolen when they are entered in the computer just as before.

Again the confusion between *me* and *my computer*

[NigelJohnstone]

From the whitepaper, again there is the confusion between *me* and *my computer*:

------
"Protection of user authentication keys
Given the large number of vulnerabilities in client system, and the trend of hackers to
target client machines looking for passwords, it is vital to provide some way to protect
sensitive authentication information such as passwords and private keys. TCPA provides
exactly this protection.
A user can generate an RSA public/private key pair on the TCPA chip. The private key
can be configured never to leave the chip."...

-----
Right, stop right there. If my private key never leaves the chip what use is it to me? It identifies my computer not me.
Whoever is at my computer, if they intercepted my login has all *my* private keys and for all purposes *is* me.

I meanwhile can move from computer to computer, but I cannot identify myself, because those private keys are on my home computer and can never move.

Why I don't think the paper tells the whole truth

[Kjella]

IBM is doing pretty much what every other business does, downplaying the bad and promoting the good sides of their product.

Soon, you will have TCPA/Media Center PCs. I'm pretty damn sure they *will* contain an endorsement key (that Microsoft will have, probably in the licencing agreement for making them), that you can not gain access to (except for a hardware hack), and that you can not emulate. This key will verify your BIOS, your Windows Palladium Media Center, and your DRM-crippled Windows Media Player. Or maybe they'll stage a few "licenced" players to create the illusion of choice.

And in the next level, I've heard that TCPA will be internal to the processor. Goodbye even to the hardware hack.

Saying the TCPA of the IBM machines doesn't have an endorsement key is saying, "yes, we're pointing this assault rifle at your consumer rights, but we haven't loaded it yet". Then when people "have to" have an endorsement key to get programs working, they can blame it on consumer demand.

Kjella

Call Me Stupid . But . . .

[GnuPengwyn]

Exactly why do I _want_ these chip[s] on my new mainboards?
It sucks case-space, and waste's Juice. (v/r=i)
I _want_ to add chip[s] to my mainboards that have things like
a TB of memory, or say a "Spare CPU slot (tm)" (sic)
In fact why not just add another CPU?!

If the white paper's _intentions_ are to be believed as stated,
this eFFing "Kradical new Chipp0r"(tm) does not need to BE
physically soldered onto the "eFFing mainboard" (tm)
They can make it a self contained appliance that plugs into the wall,
and plugs into the box (via serial, parallel, or usb)
Then when *I* _want_ to do some eCommerce or some 31134
crypto to my friends then I can plug the little bugger in,
do my Biz, then disconnect0r the SOB!

But noooooooooooooo!? that's not the True Evil Intentions.
They *HAVE* to put this BOFH on the MB's now,
cause they know folks do not take change easilly,
So they desensitize you to this crap now.
IBM, test away, research away,
hopefully someone will break it in the research lab
*BEFORE* they roll the crap out the door.
Maybe the Genius's at SuSE or United Linux
can smoke-check that lil-bugger and prove that it's flawed.

But I digress, what a whoring plethora of bullcrap TCPA is. ;o)
I think I meant plethora of whoring bullcrap.