TCPA Support in Linux

kempokaraterulz writes "Linux Journal is reporting that "The Trusted Computing Platform Alliance has published open specifications for a security chip and related software interfaces.". In the latest Gentoo Newsletter they talk about a possible 'Trusted Gentoo', and possible uses for hardware level security."

Comments

Finally ready for the main stream

[kaustik]

It really makes me happy to see that Linux distributers are finally seeing the light and providing the community with things we need in an Operating System. Hopefully this will lead to other advances in the wonderful world of DRM.
sigh

Re:Finally ready for the main stream

[yason]

It really makes me happy to see that Linux distributers are finally seeing the light and providing the community with things we need in an Operating System. Hopefully this will lead to other advances in the wonderful world of DRM.

It has been my understanding that trusted computing equals not DRM automatically. Trusted computing is initially neutral technology: the barriers are built up only after the chip gets to choose a side. You can let Microsoft turn your PC into a DRM environment using TCPA's technology but that's the Microsoftish / {MP,RI,??}AA'ish approach. You can also use TCPA to turn your Linux box into a hardware-reinforced installation of your choice. If TCPA was widespread, you could for example control how the bastard big co. digitally uses, views and copies personal information when you buy something on their website.

Tee hee... published before editing was finished

[PornMaster]

From a programmer's perspective, the IBM version of the TPM (or TCPA chip) looks like Figure 1. Garrick, please crop the caption out of the figure itself.

Garrick? Garrick? McFly? McFlyyyyyyyyyy?

Do we really need it ?

[CineK]

I mean - there are a lot of hardware security modules that can be used for building trusted systems right now.
Isn't the only purpose of pushing things like TCPA locking the platform down ?

Re:Do we really need it ?

[danheskett]

A locked down platform is very useful for some things.

One thing TCPA provides that many alternatives do not is a system of sealed storage. In this scheme, an application run under the TCPA feature set can access storage that is guaranteed by hardware to be only accessible by that one application, and no others. This storage is protected by hardware encryption, and cannot be accessed directly, even by the OS. If the application itself or any component is tampered with the sealed storage is inaccessible, since the Nexus, or hardware security manager, recognizes the binary itself as the key to the sealed storage. If that binary is modified, it can no longer access the sealed storage.

Sealed storage like this is useful in a lot of ways. Combined with a strongly encrypted internet communications a highly secure messaging system could be devised where the encryption was physically end-to-end. Since TCPA provides encryption from the keyboard, to the memory, to the Nexus to the CPU and every point in between, the plain text is only exposed when it is physically being typed - it never exisits in unecrypted digital form.

Re:Do we really need it ?

[bechthros]

Seems to me it's a lose-lose situation. On the one hand, until it's hacked, you have users not being able to have their machine do what they want it to do. That's obviously bad thing number one.

But number two comes a couple years down the road from widespread adoption, when some critical flaw in TCPA is found by hackers, TCPA is hacked, and innocent businesses that have come to depend on it for security are disrupted and exploited. And then we're looking around all doe-eyed, like, "but they said it was unbreakable security, they said it was trusted computing!" TCPA is just antoher level of command heirarchy, and subject to hack.

"Trusted computing" has got to be one of the most insidious marketing doublespeaks I've ever heard in my life. All "Trusted Computing" consists of is computers who don't trust me.

Re:Do we really need it ?

[Minna Kirai]

Oh, sure. Linux is perfectly secure, right? Keep on dreaming, it must be nice.

Oh, sure. TCPA can protect against OS bugs? Keep on dreaming, must be nice.

TCPA means that signed software can run with full permission. It only stops intentional exploits (programs specifically designed to infringe copyright), not accidental ones (buffer overflows or cross-site scripting).

To block such things, there are many well known techniques that can be applied- priviledge separation, data-tainting, external-error trapping, etc. But all of those can be implemented in sofware alone, without help from TCPA or any other hardware. Conversely, TCPA without those signficiant software changes gives zero benefit.

The only people TCPA might protect is those who put themselves at risk by running slapdash amateur software like Linux and OpenBSD, instead of staying with known quality brands like Microsoft, where security is job N!

PS. Incidently, the flaws in your argument are directly analogous to those in George W. Bush's social security plan. In both cases, to prevent a vague danger, he suggests doing 2 different activities, when really only one of them goes towards solving the difficulty at all- the other just serves his ideological agenda (and is more elaborate and expensive, to boot).

Re:Do we really need it ?

[Anonym0us Cow Herd]

And how exactly is this useful to the user? Why would I want to run an application that has its own private storage which can't be accessed by other applications or the OS?

I might want only a limited set of applications accessing a certian storage area.

• P2P application
• XMMS

Then in a different secured storage area, I only want a limited set of applications accessing....

• Usenet downloader
• Pr0n Viewer

Since I can trust the software within each group, I know that no evil RIAA people will be accessing my sacred secured storage. (Of course, torture may be allowed in the US -- after all -- think of all the poor record executives.)

Imagine a trusted P2P application that will only interconnect with the same trusted application? The trust works both ways. Just like the RIAA thinks they can "trust" their software running my computer to not be of my own creation, or a tampered version of their software, I can "trust" that MY software running on the RIAA's computer is similarly my original code, not tampered with or substituted.

Give me enough rope...

[DigiShaman]

to hang myself.

Instruction: How to restrict your Linux box from yourself.

Linus Torvalds himself has blessed DRM

[Xpilot]

Linus himself said DRM is ok, as long as it's used in the interests of the user. This is a good thing, think about it; EvilCorp(tm) wants to use DRM to cripple computers, but the PR guy will say "it's for the user". Of course their intent is nothing of the sort, but the Linux folks are the only ones who will actually implement something that *is* in the interest of the user. Then EvilCorp won't be able to lobby making Linux illegal, since Linux also uses DRM which does what EvilCorp claims it's doing "for the users". Well, hopefully.

Re:Linus Torvalds himself has blessed DRM

[Minna Kirai]

Linus himself said DRM is ok, as long as it's used in the interests of the user.

Linus is not a lawyer. More importantly, he's not even a free software or open source evangelist. Unlike RMS or ESR, he doesn't even hang out with lawyers or devote serious thought to legal matters.

Since DRM is a combined legal-technical area, it falls outside Linus's expertise, and his opinion carries little weight. (From a practical standpoint, TCPA is incompatible with the Linux philosophy of open-source modifications)

Lacking One Thing

[SpottedKuh]

Though the specifications detailed in the article are definately a Good Thing, they lack (at least as far as I could tell) any way of preventing unauthorized physical access to the chip.

Physical access to machines is always a big issue in security, and one that is often overlooked. And while it's probably not a big deal for your home machine, consider large companies whose machines could conceivably be targetting for a physical attack to recover the keys directly from the TPM (Trusted Platform Module).

Stajano's "Ubiquitous Computing" book has excellent coverage of the rationale, issues, and complexity of attempting to prevent physical access to chips and devices which store sensitive information. It's an easy read, and well worth it: http://www-lce.eng.cam.ac.uk/~fms27/secubicomp/ind ex.html

Hardware Security

[quadra23]

This is indeed good news! Security that is solely-based on software is far easier to compromise than hardware-based (provided that the hardware can't be tampered with by malicious software). Far better to have the security co-ordinated between both. I'd be interested to see how widely accepted this open specification will be.

Re:If you can't beat 'em, join 'em.

[SpottedKuh]

Trusted Windows

Wait, wait...you lost me on that one.

Wouldn't that be...

[GbrDead]

Treacherous Gentoo?

TCPA is a DRM smokescreen

[Hobbex]

It has been said a million times, yet apparently it bairs repeating. The "security" aspects of TCPA are redundant, unnecessary, and at best useful but could be made a lot better if the chip was designed for security rather than DRM. The whole system really exists only for one purpose: as a trojan horse to implement something called "remote attestation" in PCs.

What is remote attestation? Basically, it means that the TCPA chip, which you cannot control, can read what operating system you have loaded, and send a reponse proving that you are running a certain operating system to others on the Internet. The purpose of this, of course, is so that the operating system can be verified not to have it's DRM functions cracked, so that the RIAA and MPAA can send you data and make sure that they get to decide what you do with it.

The people pushing TCPA will claim that it is not for DRM, but that is a smokescreen and only a smokescreen. While TCPA does not do DRM itself, it is the enabling component that is needed so that software can implement DRM without being circumventable.

What does this mean for a "trusted Linux"? It means that while it is completely possible to have a Linux system working with TCPA, once you change anything in the system, the TCPA chip will notice you are running a modified system, and nolonger let your data. So while the software may nominally remain under the GPL, it will be the death of the free software model, because users who wish to tinker with their systems will be locked off the Internet (Cisco is already talking about systems to have ISPs demand remote attestation when TCPA is in place). TCPA and Linux can be combined in theory, but only in theory - in reality they cannot ever coexist.

Those who do not believe me (or those who are inclined to believe the MS shills who will respond saying that I am wrong), should read EFFs analysis of TCPA where they give a simple way that the chip could be changed to allow all uses except remote attestation intended to force people to use certain operating systems and enforce DRM over the user. It has been completely ignored by the manufacturers of TCPA.

Re:TCPA is a DRM smokescreen

[Hobbex]

The tenacity of your attempts to replace logic with rhetoric would be impressive if it wasn't so braindead.

And casinos likewise operate without any oversight or auditing whatsoever. Millions of people play these games every day. Adding security can only benefit them.

No, adding a sense of false security does not make things better. People who play on online casinos today do not expect there to be software controling that the game is fair: to the extent they care they go by reputation and testing just like I suggested. TCP adds nothing - absolutely nothing - to make this more secure. The same thing goes for voting.

You're the one who's got to be kidding! Have you not heard of the many new forms of malware which are going after banking account numbers and infiltrating themselves into secure banking transactions? TC can stop these cold via sealed storage and remote attestation. Again, you are arguing that we should deny users access to these technologies purely for political reasons because you don't like the technology.

If the TCPA application of your bank were intended to stop malware, then it would have no problem with the EFF's proposed owner override. So once again with the lies!

I won't go through the rest of your "analysis" because it's the same kind of bullshit.

LOL. "I won't even begin to counter your arguments that the world is round because it is such bullshit."

My guess is that you are worried that TC will make it harder for you to pirate your favorate songs and movies.

No, no, try harder: what I actually care about is abudcting and sexually abusing small children. And strangling puppies. And helping the turrists!

TCPA is a technology designed from the ground up for exclusion. The fundamental question of the next century, as with the previous ones, is whether we wish to build and open society or a closed one, and TCPA is ultimate tool for those who wish to close our networks. The goal of TCPA is facilitate the handing over of control of our communication devices to others, so that our computers can decide what we cannot and cannot do with them, can and cannot run with them (if we still wish to access our data and the Internet), and ultimately dictate the parameters of all networked communication. Anyone who accepts TCPA accepts that he should live in digital prison, that his doors should be locked from the outside, that a priori restraint should be placed on his ability talk to others, and that not only the Internet, but all computing and all our data should be placed in the hands of a centralized few.

You, sir, disgust me.

Trusted Linux is ILLEGAL

[Minna Kirai]

It's very simple:
1. Linux is distributed under the GPL (and other licenses).
2. To comply with the GPL, end-users must be able to acquire the source code (which means everything they need to reproduce the binary executble, with or without modifications).
3. If you don't comply with the GPL, you are committing copyright infringement, a federal offense.

But from the other direction:
4. Trusted computing means that all binaries are signed with a secret key.
5. The Trusted CPU will not execute binaries that weren't signed with that key.
6. In this way, it is impossible for end-users to create modified binaries to add/remove features from the software.

The GPL is too much in conflict with Trusted Computing to ever allow them to work correctly together. To obey the GPL, end-users must have access to everything needed to rebuild working binaries- which includes the secret key. But for Trusted Computing to work, it must be impossible for end-users to get the key- otherwise there's no point.

So, Linux or Trusted Computing. Choose one, because you can't have both.

Re:Trusted Linux is ILLEGAL

[SiliconEntity]

4. Trusted computing means that all binaries are signed with a secret key.
5. The Trusted CPU will not execute binaries that weren't signed with that key.
6. In this way, it is impossible for end-users to create modified binaries to add/remove features from the software.

This is total garbage. Where did you get this nonsense?

TC does not require binaries to be signed with a key. TC will not refuse to execute unsigned binaries. And end users can do whatever they want.

Now for the facts, in case you're interested. TC implements a secure boot. This allows the TPM chip to store a hash or fingerprint of your software configuration: the BIOS, the boot loader, the OS, and if desired, the applications that are running.

The TPM and OS can basically do two things with this information. They can implement "sealed storage" which means that a program can lock its encrypted data to the current software configuration. This means that if you boot a different OS, or if the program gets modified (either of which might happen due to virus infection), the fingerprint changes and the data will no longer be available. Likewise if another program tries to access the first program's sealed data, it won't be able to get access to it.

The second feature of the TPM is "remote attestation". This allows a program to request the TPM to issue a cryptographically signed statement about what the current software fingerprint is that is running. This signed attestation cannot be forged because the TPM generated an on-chip key at manufacture time, and the manufacturer issued a certificate on that key which the chip can use to prove to anyone that it is a legitimate TPM.

Remote attestation allows network applications to determine what software configuration the peers are running, and, if they choose, to disallow participation by software which is not running a specified set of configurations. This is the closest you will come to the idea that users can't change their own software. If they want to run a program which relies on this feature, and that program doesn't accommodate the changes the user wants to make, they would be shut out. But in practice, open source programs will probably be flexible in this regard as they will want to have as many people as possible participate. There are a number of technical measures which can be adopted to allow for considerable user flexibility.

But certainly none of this would violate the GPL or any other legal prohibitions. Everything is entirely voluntary, and Trusted Computing does not prevent you from doing what you want with your computer. You don't even have to turn it on if you don't want to!

Re:Trusted Linux is ILLEGAL

[finkployd]

Completely wrong. The owners of machines don't get the keys needed to sign things for their own hardware. Only the builders of the hardware have those keys, and they are contractually obligated by agreements to the MPAA and RIAA not to divulge those keys to anyone (except employees in the course of their work).

Wow, you just don't have a single clue about any of this do you? You can pop whatever keys you want into the hardware. If you want to create a system where only binaries signed by you can run, go for it. If you only want to run binaries signed by debian, redhat, or joe blow down the street, you can do that too. You can also turn off this checking and allow anything to run.

The scary part of this is the remote attestation piece. THIS is what the riaa and mpaa want. It basically allows streaming media servers and media files to only be opened by programs signed (and verified by the hardware) by those they trust, like microsoft. A scary vision of this is that windows file sharing could disallow samba clients to connect to it even if the open the protocol, because samba was not signed by Microsoft.

If the owners of the hardware were going to be the ones having the keys needed to run on that hardware, then I wouldn't have any problem with it.

You are not going to get Microsoft's signing key and be able to sign your binaries as them, but you will certainly get their public key to verify their binaries and put that in your hardware. You can also generate your own key to sign with and put that public key in the hardware too.

Do you honestly believe that anyone, anywhere would ever go for a system where all software running on Windows has to be signed by microsoft? They couldn't even do that with signing device drivers and such (although they tried, all it does is warn you). You think microsoft is going to stop selling visual studio and all their programming tools because nobody but them can create and sign binaries? Now take this a step further, do you think overseas PC makers are going to sell PCs that can only run windows? Even US companies would never do that.

Good God man, actually take some time and learn about this stuff before you spout uninformed drivel everywhere. There are some real legit complaints about TCPA, but you seem to not understand the most basic aspects of it.

Finkployd

As sad as it is

[Anonymous Coward]

To have to burst your bubble of uninformed zealotry, there are plenty of good uses for trusted computing and DRM that do no interfere with your quest to get 'fr33 musicz 4 life' or whatever. Not all of this technology is for companies like the RIAA to protect copyrights, despite what Slashbots would have everyone think.

Re:As sad as it is

[cayenne8]

" This is not flamebait. I hope someone with a brain mods you up...If anything, the original parent was the flamebait..."

In general...sure...TCPA could have some positive effects on the computing community. However, it also has great potential to be slipped in...and eventually, by law, it must be used to lock things down. Only a few things at first...but, eventually could mandate a great deal of limitations as to what you can legally do with a computer. As much as the corporate entities are beginning to use the govt. to legislate things...and they really don't like the fair use we do have...it is easily possible to forsee this as a means to that end.

Taken long enough...it could happen, which is why you need to take things like this slowly and with a great deal of skepticism early on.

I heard it said before that "What one generations tolerates....the next generation embraces"

Think of it this way...the article the other day on /. about how many US kids don't understand what the 1st amendment really means...they haven't been taught about it...and we're tolerating loss of freedoms. When they are grown and we're not around...they won't even know they existed in the old form...

TCPA - TCG

[SiliconEntity]

It hasn't been called the Trusted Computing Platform Alliance, TCPA, for a couple of years now. It's now the Trusted Computing Group, TCG. Same technology, just a new name.

Re:what is it good for?

[vadim_t]

Well, it could be useful for a seriously locked down server.

Imagine that you're an admin at some big company, with a hundred Linux boxes. You have this stuff on every of those boxes, and a computer for administration somewhere safe. When you install software you first check it, then sign it, then push updates to your servers.

If somebody gets in, they'll have things quite difficult. Anything unsigned simply won't run at all. Rootkit modules, exploits, etc, will all simply not be able to run at all. This would take out a quite big part of the exploits an attacker could use. Remote ones would hopefully avoided by NX.

This wouldn't protect against things like races, but it certainly could help quite a lot.

The situation above is something I wouldn't have any problems with. If an admin wants to have an uber-locked down system where anything not signed by his key that's only present in a computer with no network connection in a secure room with an armored door doesn't run at all, then sure, why not. I'm fairly sure this can mostly be accomplished without hardware support at all, though.

Now, it's when software publishers want to make it impossible for me to control my computer when I have problems with it. But if the user has full control of it, I think it could come quite handy in some cases.

Re:what is it good for?

[Qzukk]

When you install software you first check it, then sign it, then push updates to your servers.

In the end, it depends on who gets to sign the software, and how this software is distributed once signed. In our corner of the court, we have the admin signing software for 100 boxes (does he have to sign each separately? Can you sign software for every box out there at once? If its not a specific-to-that-machine signature, how do you keep the attacker for signing software too?) for the purpose of protecting the servers from software you don't want to run.

In the other corner of the court, it appears that we have big business interests who want to have all software signed, who would charge hundreds to sign software for other authors (verisign, et al will certainly be in the business), MPAA and RIAA will be wanting to make sure signed software obeys their rules (and will probably charge for this too), all to make sure your computers are protected from software they don't want you to run.

Things like this IBM article help make the first scenario a reality, and I'm grateful for it. Now, who wants to be the first to be sued by Microsoft for some TCPA submarine patent that nobody knows about?

Here comes the flood??

[Reziac]

From TF WhitePaper [PDF] on IBM's site:

The "trusted" boot functions provide the ability to store in Platform Configuration Registers (PCR), hashes of configuration information throughout the boot sequence. Once booted, data (such as symmetric keys for encrypted files) can be "sealed" under a PCR. The sealed data can only be unsealed if the PCR has the same value as at the time of sealing. Thus, if an attempt is made to boot an alternative system, or a virus has backdoored the operating system, the PCR value will not match, and the unseal will fail, thus protecting the data.

At the very least, that sounds like "bye-bye multi-boot systems".

IBM also has a rebuttal to TCPA's detractors [PDF]. This one talks more about how the TCPA chip as currently designed "not been designed to resist local hardware attack, such as power analysis, RF analysis, or timing analysis." That's all well and good for the moment, and while the chip is (per the PDF) mounted on a presumably-removeable daughterboard, but how about the future? Is this how TCPA will stay, or is it the beginning of our worst fears??

At least these two whitepapers agree with most of us here on one thing -- DRM itself is stupid, for a variety of reasons.

Re:Here comes the flood??

[Reziac]

That's a good point. What's the difference between a "different" OS and an "upgraded" OS? A: Nothing -- either way, it still won't match the "original" OS.

And as you point out (re SP3 over SP2) -- what's to stop the OS from refusing to play nice if it doesn't encounter the PCR that it expects to see?? Might you have to provide your PCR when the OS is activated, and then you only get updates if the PCR still matches??

Can, meet worms.

Re:Here comes the flood??

[Greger47]

This is the thing that I don't get. The supposedly secure boot process seems to be broken from start to finish.

The "trusted" boot functions provide the ability to store in Platform Configuration Registers (PCR), hashes of configuration information throughout the boot sequence. Once booted, data (such as symmetric keys for encrypted files) can be "sealed" under a PCR. The sealed data can only be unsealed if the PCR has the same value as at the time of sealing. Thus, if an attempt is made to boot an alternative system, or a virus has backdoored the operating system, the PCR value will not match, and the unseal will fail, thus protecting the data.

The whitepaper also mentions that in IBMs implementation the chip is connected to the SMbus.

This means that the entire security of the boot process hangs on whatever data the CPU feels like sending to the chip for hashing. I could as well make a patch for GRUB that sends the "secure" version of GRUB down the SMbus and actually executes whatever nastiness I have in store.

In the case of DRM this lets me run whatever OS I want. The only thing I have to do is to feed a copy of whatever OS Hollywood trusts to the chip and voila the chip will say I'm legit and Hollywood will give me access to their movies for me to pirate at my leisure. :)

As I see it, the only way to get this to work for real is if Intel steps up and builds TCPA support into the CPU itself such that the PCR register is continuously updated as each instruction is executed. And all existing external chips have to be blacklisted, ofcourse.

Or does the TCPA system have some other trick up their sleeve that makes this work even though it's implemented externally to the CPU?

/greger

Re:Here comes the flood??

[SiliconEntity]

This means that the entire security of the boot process hangs on whatever data the CPU feels like sending to the chip for hashing. I could as well make a patch for GRUB that sends the "secure" version of GRUB down the SMbus and actually executes whatever nastiness I have in store.

That's a clever idea, but it doesn't work. The secret is that the trusted boot process uses a concept of "trust extension". We start off with the BIOS. That takes a hash of itself and sends it to the TPM. Then the BIOS will load and run the boot loader. But - and here is the key - before running GRUB, the BIOS take a hash of GRUB and sends it to the TPM. Then it runs GRUB.

The next step is that GRUB - or at least the TPM enabled version, performs a similar process for the OS kernel. It first takes a hash of the kernel and sends it to the TPM; then it runs the kernel. And the kernel can repeat the process with the various startup scripts and other programs that loads, a la tcgLinux or the Enforcer.

The key point is that before each component is loaded, it is "measured" (i.e. its hash is reported to the TPM). So you can create a bogus GRUB or a bad kernel, but this fact will show up in the TPM's configuration registers because your bad component got its hash reported before it ran.

The one exception is the BIOS, but TPM systems are supposed to have restricted BIOS flash capabilities so you can't re-flash the part of the BIOS which does the initial hash of itself. This is part of what they call the Core Root of Trust for Measurement (CRTM) and it is supposed to be inviolable.

not entirely so

[hany]

From a practical standpoint, TCPA is incompatible with the Linux philosophy of open-source modifications

IMO this is not exactly correct - is it against Linux philosophy of open-source modifications to secure my Linux box so nobody except me can make modifications to it?

TCPA used in such way (i.e. in interest of user, not supplier, not government, ...) is quite in line with Linux philosophy of "you're in control" :) .

But, as with all weapons, it has two edges. So, beware! :)

Re:Software DRM

[SiliconEntity]

Since the source is available for Linux, what would stop someone from sandboxing 'trusted' software by having the OS validate code before it's executed (slow, though a bit faster than emulation and without all the bugs), and then implenting the DRM hardware (or BIOS) instructions in software in a way that stores the keys (or plaintext information, if that is not doable) and allows access to any software to get the info.

This is one of the most commonly asked questions about the TPM. The answer is that the TPM implements what is called a "secure boot" sequence.

The first thing that happens in a TPM enabled computer is that the BIOS, on startup time, sends a hash of itself to the TPM. Then, when the BIOS goes to load the OS, it sends a hash of the boot loader (grub, in the case of Linux) to the TPM. The boot loader will be modified (see the Trusted Grub project) to take a hash of the OS kernel and send that to the TPM. And the OS itself will be modified (a la tcgLinux to take a hash of the various OS components, startup scripts, and programs as the computer boots.

The net result is that the TPM has a record of what OS was booted and what the software configuration is that is running. This allows it to distinguish between a "real" boot and an emulated one, because in the latter case it sees a hash of the emulator being loaded.

Software which runs in un-emulated mode and uses the TPM features can distinguish that case from when it is running emulated. If it locked some data using the TPM in the first mode, it won't be accessible in the second mode.

Once remote attestation is possible, networked applications will be able to report their software configuration to each other. This will be unforgeable because the TPM will sign an attestation of the software configuration, and the TPM itself will have a certificate from the manufacturer attesting that it is a legit TPM. Your emulator will not have a certified TPM key (those stay on the chip) and so it won't be able to come up with a credible forged attestation. Programs running on emulators won't be able to take part in network security applications that use these features.

Re:TCG and Linux make sense

[praedor]

Hmmm. And yet I don't seem to need any form of TCPA/TCG or DRM. In all the years I've run linux full-time, I have never ever had naughty code or naughty hackers get in. I can't say that about any of the windoze users I know. Beyond that, I certainly don't need any system that can be used as a DRM system.

Nope. Uh-uh. Not on my box. I'll copy my files and CDs as I feel the need and will not have anyone but me control when and how I go on to use such copies. This all looks like what it is, an attempt by corporations to gain control of the most important and useful aspects of your PERSONAL and private property computer. Screw TCPA/TCG (and DRM). Paint it all up with lipstick and rouge all you want but in the end it is about restricting what people are allowed to do with their own computers. Any benefits that come to the individual computer owner are accidental and peripheral to the actual designed and intended purpose.

RMS's writing about "trusted" computing

[latroM]

RMS has written a nice article about it: see http://www.gnu.org/philosophy/can-you-trust.html