Dartmouth Project Combines Linux With TCPA

SiliconEntity writes "A new project from Dartmouth College demonstrates significant advances in combining Linux with TCPA. The software turns a Linux PC into a 'virtual secure coprocessor', which is able to check that none of its software is compromised and even (in a future version) prove its integrity to a remote system. Full GPL source code is available for the 2.4 kernel. This work is separate from the earlier IBM research which also combined Linux with TCPA, with the new project apparently more complete and with a road map towards a very functional Linux based trusted computing system. This could be an important technology for Linux to challenge Microsoft as it pushes forward with NGSCB (aka Palladium)."

Comments

Re:Sweet

[rowanxmas]

This is innovation. Microsoft, from what I understand is planning a pay-for-it system where trusted means, that someone bought a liscence. IT will be interesting to see how well ms-trusted-apps stand up to a similar test.

Re:Sweet

[advocate_one]

I think you'll find Linux will have it well before MSFT does... and it'll work... and it won't require special hardware either. And you'll be able to double check the source code instead of having to take it on trust...

The source code

[OpenSourcerer]

>Full GPL source code is available for the 2.4 kernel

Please make sure that all the efforts are undertaken to remove any references to the construct 'main()' as it will infringe on SCO copyrights

Re:The source code

[kasperd]

main() as it will infringe on SCO copyrights

Luckily no important part of Linux uses that construct. It is mentioned a few times in the documentation and comments, but we can remove that without breaking anything. (Hint: Linux is a kernel, not a program.)

Re:The source code

[Anonymous Coward]

oh, just quit complaining and pay your $699 licensing fee.

Re:The source code

[sholden]

Does it takes lots of efforts to be that stupid?

$ find linux-2.6.0-test5 -name '*.c' | xargs grep '^int main('
linux-2.6.0-test5/drivers/scsi/aic7xxx/aic asm/aica sm.c:int main(int argc, char *argv[]);
linux-2.6.0-test5/drivers/atm/fore200e_ mkfirm.c:in t main(int argc, char** argv)
linux-2.6.0-test5/arch/i386/boot98/tools/bu ild.c:i nt main(int argc, char ** argv)
linux-2.6.0-test5/arch/i386/boot/tools/buil d.c:int main(int argc, char ** argv)
linux-2.6.0-test5/arch/sparc/boot/piggyback .c:int main(int argc,char **argv)
linux-2.6.0-test5/arch/sparc/boot/btfixup prep.c:in t main(int argc,char **argv)
linux-2.6.0-test5/arch/sparc64/boot/piggy back.c:in t main(int argc,char **argv)
linux-2.6.0-test5/arch/um/kernel/skas/uti l/mk_ptre gs.c:int main(int argc, char **argv)
linux-2.6.0-test5/arch/um/sys-i386/util/m k_thread_ kern.c:int main(int argc, char **argv)
linux-2.6.0-test5/arch/um/sys-i386/util/m k_sc.c:in t main(int argc, char **argv)
linux-2.6.0-test5/arch/um/util/mk_constan ts_kern.c :int main(int argc, char **argv)
linux-2.6.0-test5/arch/um/util/mk_task_ke rn.c:int main(int argc, char **argv)
linux-2.6.0-test5/arch/um/main.c:int main(int argc, char **argv, char **envp)
linux-2.6.0-test5/arch/mips/boot/elf2ecof f.c:int main(int argc, char *argv[])
linux-2.6.0-test5/arch/cris/arch-v10/ker nel/asm-of fsets.c:int main(void)
linux-2.6.0-test5/arch/cris/arch-v10/b oot/tools/bu ild.c:int main(int argc, char ** argv)
linux-2.6.0-test5/arch/m68knommu/kernel/asm -offset s.c:int main(void)
linux-2.6.0-test5/arch/arm26/boot/comp ressed/misc. c:int main()
linux-2.6.0-test5/arch/arm26/kernel/asm-of fsets.c: int main(void)
linux-2.6.0-test5/arch/m68k/kernel/m68 k_defs.c:int main(void)
linux-2.6.0-test5/arch/m68k/tools/amig a/dmesg.c:in t main(int argc, char *argv[])
linux-2.6.0-test5/arch/ppc/boot/prep/dum my.c:int main(void)
linux-2.6.0-test5/arch/ppc/boot/openfi rmware/dummy .c:int main(void)
linux-2.6.0-test5/arch/ppc/boot/simple /dummy.c:int main(void)
linux-2.6.0-test5/arch/ppc/boot/utils/ addSystemMap .c:int main(int argc, char **argv)
linux-2.6.0-test5/arch/ppc/boot/utils/add RamDisk.c :int main(int argc, char **argv)
linux-2.6.0-test5/arch/ppc/boot/utils/mkb ugboot.c: int main(int argc, char *argv[])
linux-2.6.0-test5/arch/ppc/boot/utils/mk prep.c:int main(int argc, char *argv[])
linux-2.6.0-test5/arch/ppc/boot/utils/mk tree.c:int main(int argc, char *argv[])
linux-2.6.0-test5/arch/ppc/boot/utils/ad dnote.c:in t main(int ac, char **av)
linux-2.6.0-test5/arch/ppc/boot/utils/mknot e.c:int main(void)
linux-2.6.0-test5/arch/ppc/kernel/find _name.c:int main(int argc, char **argv)
linux-2.6.0-test5/arch/ppc64/kernel/asm-o ffsets.c: int main(void)
linux-2.6.0-test5/arch/ppc64/boot/pigg yback.c:int main(int argc, char *argv[])
linux-2.6.0-test5/arch/ppc64/boot/addSys temMap.c:i nt main(int argc, char **argv)
linux-2.6.0-test5/arch/ppc64/boot/addRamD isk.c:int main(int argc, char **argv)
linux-2.6.0-test5/arch/ppc64/boot/mknote. c:int main(void)
linux-2.6.0-test5/arch/arm/kernel/asm- offsets.c:in t main(void)
linux-2.6.0-test5/arch/arm/boot/compre ssed/misc.c: int main()
linux-2.6.0-test5/arch/parisc/kernel/asm-o ffsets.c

Re:The source code

[OpenSourcerer]

Sorry, I can't. My account is in overdraft since i paid 2000 bucks to RIAA

Re:The source code

[kasperd]

$ find linux-2.6.0-test5 -name '*.c' | xargs grep '^int main('

The mentioned code was 'main()', not just 'main('. When you start looking for substrings, you can obviously find them everywhere. It is not like I have copyright on the letter I though it appears in a message I wrote. Look for the correct sequence like I did, and you will see most occurences in documentation and comments within drivers I don't use anyway.

Re:The source code

[Anonymous Coward]

The mentioned code was 'main()', not just 'main('.

Oh, please. You were proven wrong, and instead of S[ing]TFU and moving on, you instead return to argue over semantics.

Re:The source code

[Anonymous Coward]

Don't confuse stupidity with ignorance.

Re:The source code

[Anonymous Coward]

So in other words, though you have no trouble being an idiot, you have difficulty admitting it?

Oh, by the way, a kernel is a program. Just so you know and all. Stupid fuck.

Re:The source code

[jd]

main(), in K&R syntax, is trademarked, copyrighted and patented by SCO. In fact, everything either K or R did is trademarked, copyrighted and patened by SCO, including all descendents, cell division, breathing, etc.

Re:The source code

[jd]

That's ok, 'cos their ANSI syntax, not K&R.

Parameterless function calls/definitions (eg: main()) may be either, but SCO's lawyers have #defined all of K&R's work to be theirs.

Re:The source code

[Krunch]

Remember to remove any reference to stdio.h too.

Re:The source code

[Krunch]

Forgot to give the url. Sorry.

Re:The source code

[arkane1234]

The mentioned code was 'main()', not just 'main('. When you start looking for substrings, you can obviously find them everywhere.

Alright, to play your little game:

arkane@whq-hyperion /root$ cd /usr/src/linux && find . -name '*.c' | xargs grep '^int main()' ./arch/alpha/kernel/check_asm.c:int main() ./arch/arm/boot/compressed/misc.c:int main()
arkane@whq-hyperion linux $

Do stop while you're ahead.

Re:The source code

[arkane1234]

I just re-read the original post... even worse.
just main() brings:
./drivers/net/skfp/smtparse.c:main()
./drivers/isdn/hisax/rawhdlc.c:main()

Re:The source code

[pantycrickets]

Sorry, I can't. My account is in overdraft since i paid 2000 bucks to RIAA

Dont forget the $3,500 to DirecTV!

Re:The source code

[CentrX]

Aside from there being several main()'s in the code as other commenters have posted, there are also many int main(void) in the list that the parent provides, which is functionally identical, or at least nearly so.

Re:The source code

[sholden]

The mentioned code was a *joke*. I don't think which of the half a dozen or more forms of main() was the point.

You declared:

Hint: Linux is a kernel, not a program.

The kernel source contains a file containing nothing but:

int main(void)
{
return 0;
}

Which indicates your understanding of the inclusion of constructs like main() in kernel source is less than perfect.

An intelligent person might joke that ANSI isn't covered, since SCO's IP is all K&R, but of course you aren't and you didn't...

Not compatible with eachother ?

[MoonFog]

From the PDF :
The exact relation between TCPA and the former Palladium is not clear; one suspects that at some point in the TCPA design process, Microsoft decided to withdraw and build their own variant.
This probably means the two technologies will not be compatible with eachother, files created under one will not be able to be opened under the other.

Re:Sweet

[advocate_one]

and it won't require special hardware either

correction... just managed to get into the site... it will require a "Trusted Computing Module" on the motherboard.

Re:Sweet

[MoonFog]

The TCPA is a comitee and is not something that belongs to Microsoft, although they are part of this comitee. IBM are also working on a TCPA technology. Palladium, or whatever it is called now, is perhaps the most "famous", but definately not the only one.

actual secure coprocessor

[!the!bad!fish!]

'virtual secure coprocessor'
Where's an actual secure coprocessor?

Re:actual secure coprocessor

[Anime_Fan]

That's 'virtually secure coprocessor'.

A coprocessor that's 'actually secure' is something we'd all want but never would get.

Re:actual secure coprocessor

[OpenSourcerer]

'virtual secure coprocessor'
When you try to break in, it stops you and gives you a lecture with quotes from the Bible. Makes you a better person

Don't like pdfs? Here's the TCPA paper in HTML

[flopsy mopsalon]

http://216.239.33.104/search?q=cache:nZrXhIU65ocJ: www.cs.dartmouth.edu/~sws/papers/msmw03.pdf:&hl=en &ie=UTF-8

Re:Sweet

[Anonymous Coward]

I hate to break it to you but MS did NOT create TCPA!!!!

Perhaps you mean they where following in MS's footsteps by creating an OS that works with TCPA? WTF is wrong with you? Haven't you ever heard of the term vaporware? lol....true I think it's safe to say MS actually has one but which do you think is going to produce one first to the market? TCPA isn't MS's pet project...it isn't MS's IP...

Oooh! Verifiable integrity and an encrypted FS.

[Read Icculus]

Sounds like just the thing I need. That hacked together script that I currently use to md5sum all my important system binaries + files and verify them against the Known Goods database every 2 minutes is going out the window along with chkrootkit just as soon as I can go over every LOC with an STM and run this fine piece of software. Thanks be to you my fellow linux-users, I have finally found people who wear more layers of foil on their heads than I.

Re:Oooh! Verifiable integrity and an encrypted FS.

[Anonymous Coward]

"Sure I'm paranoid, but am I paranoid enough?"

Well... obviously not.

Re:Oooh! Verifiable integrity and an encrypted FS.

[OpenSourcerer]

I am afraid you are not paranoid enough

Re:Oooh! Verifiable integrity and an encrypted FS.

[Illbay]

And just because you're paranoid doesn't mean they're not out to get you.

Re:Oooh! Verifiable integrity and an encrypted FS.

[Anonymous Coward]

"Sure I'm paranoid, but am I paranoid enough?"

Well, are you aware yet that although fortunately there are people out to get the people out to get you, unfortunately there are people who are out to get the people who are out to get the people who are out to get you?

Re:Oooh! Verifiable integrity and an encrypted FS.

[cbiltcliffe]

md5sum all my important system binaries + files and verify them against the Known Goods database

So what happens if somebody changes a system file and at the same time hacks your Known Goods database to make the new file be accepted as good?

You might want to put some of that tinfoil over the top of your computer, too.... ;P

Re:Oooh! Verifiable integrity and an encrypted FS.

[mikeee]

I have finally found people who wear more layers of foil on their heads than I.

You fool! If you wear more than one layer the psychotronic carrier waves will resonate and penetrate the barrier!

Buh-bye

[Anonymous Coward]

Well, it's been fun using Linux. Off to *BSD now, I guess.

Difference between Palladium and TCPA

[kompiluj]

The difference between Palladium and TCPA (Trusted Computing Platform Architecture) may be not obvious at the technological level but it is very simple - TCPA aims at integrity of kernel and system components - to assure you that your system can be trusted. It is easy to achieve with open software, because the system must defend itself from attacs from outside. Palladium, on the other hand, uses similar technology to make sure that the user does not do anything else than what is allowed by content owners. In that case software openness is impossible - otherwise you could do some harm to their system - attacking from inside...

So similar architecture from technical point of view - but different aims yield different results.

Re:Difference between Palladium and TCPA

[hanssprudel]

Not true at all. DRM and other user control systems only need to be closed when they are software based, because otherwise people can change the programs to remove the user hostile code.

The difference between Palladium and TCPA is really that while Palladium is a whole system for a building user hostile computers, TCPA is just an enabler.

What TCPA does is sign a hash of the OS that is loaded with an "endorsement key", embedded in the TCPA by the vendor and unaccessible to the user. Thus the TCPA chip is a able to do two things: it can verify to an outside source (that trusts the vendor) that the machine is a running a specific operating system (ie one that supports DRM and thus can be "trusted"), and it can encrypt data from one operating system so that another operating system cannot decrypt it.

TCPA provides everything that is needed at the hardware level to write any user hostile system on top of it, because the successive verification of signatures prevents any tampering with the code (even if the OS is open sourced). Palladium could be implemented with TCPA as it's only hardware aspect.

Thus, the argument that is sometimes seen here that TCPA would prevent the computer from booting Linux or any other operating system is false (incorrect scare tactics against these systems are unfortunate, they do more harm then good). What TCPA will do, is enable sites on the Internet to not allow you to read the data they give out, unless you are running an operating system that is user hostile and DRM friendly (and not in the "this site doesn't support mozilla" fashion, which can always be hacked around, but in a cryptologically safe fashion).

Re:Difference between Palladium and TCPA

[Anonymous Coward]

> Thus, the argument that is sometimes seen here
> that TCPA would prevent the computer from booting
> Linux or any other operating system is false

True .. but tell me:
1) Of what use is a Linux system, if no content can be decrypted on it?
2) Will content-providers make content available to versions of Linux which can't be "trusted"?
3) If you make a "trusted" version of Linux, will it then be modifiable by the user (say, a new kernel-patch)?
4) Of what use are Open Source advantages, if you cannot use them?
5) Is this a threat to the Open Source development model?

Re:Difference between Palladium and TCPA

[hanssprudel]

True .. but tell me:
1) Of what use is a Linux system, if no content can be decrypted on it?

Not much.

2) Will content-providers make content available to versions of Linux which can't be "trusted"?

Undoubtably not. But what format they release the data in is their concern.

It is important to remember that the only political issue here is fighting laws against compulsary DRM and laws against circumventing it where it exists. We should not fall into the whiner trap of trying to claim that we are somehow entitled to "content" in open formats. We are not.

The manner in which we should fight DRM is to explain to be people why they should not accept it. (And we need to start here on Slashdot - look at how many Slashdotters laud iTunes).

3) If you make a "trusted" version of Linux, will it then be modifiable by the user (say, a new kernel-patch)?

It will be modifiable of course, but then you are back to 1).

4) Of what use are Open Source advantages, if you cannot use them?

Not much.

5) Is this a threat to the Open Source development model?

Definitely.

Re:Difference between Palladium and TCPA

[Anonymous Coward]

I'm glad that we agree on all points.

> It is important to remember that the only
> political issue here is fighting laws against
> compulsary DRM and laws against circumventing it
> where it exists.

I agree. But these laws are in place as we speak - also in the EU.

Ironically politicians are considering laws requiring open standards in public communication.
TCPA can be made an open standard. It will still kill Open Source though.

Re:Difference between Palladium and TCPA

[OeLeWaPpErKe]

Except of course, you yourself cannot declare a kernel as safe, only one of the big companies can.

Re:Difference between Palladium and TCPA

[sjames]

Like many things, TCPA is a neutral technology. If the TCPA just sits on the board unused, you'd never know it's there at all. With Palladium, your system will be actively user hostile and RIAA/MPAA/MS friendly.

TCPA in itself won't prevent booting Linux. The fear is that a BIOS could then be written that won't load an OS that isn't signed by Bill Gates. TCPA merely enables that non-functionality. In addition, it is entirely possible to have a CPU come up in crippled mode until it validates the BIOS against the TCPA so that an unsigned BIOS won't run either. That is the fear, a total lock-down.

On the other hand, if the user has the signing key (I say user, since in reality, whoever has the signing key is the owner), TCPA permits (but does not assure) user friendly, outsider hostile strong system security.

The problem is that we are all aware that certain corporations in the U.S. would happily torture all of their customers to death if it was shown that after all of the lawsuits are settled, they make an extra $0.10 over the next 5 years than they would otherwise. They will be more than happy to build a user hostile system and lease it to their customers if they can find a way to kill off the competition.

Even if the lease is called a sale, I maintain that it's in reality a lifetime lease since, as I said, whoever has the signing key is the real owner of the system.

One possible roadblock to that would be to get the above paragraph enshrined in law. Not only would that force vendors to be more honest in their sales of Palladium enabled systems, it would place a nice large tax burden on a corporate holder of the signing key since they would be forced to acknowledge that they actually own all that hardware out there. More likely, it would kill the whole thing since under that law, hardware vendors would have to treat the transaction as a gift to MS and themselves as a lease broker for MS.

Re:Difference between Palladium and TCPA

[Anonymous Coward]

But I can already trust my Linux systems, so there is no point to TCPA.

Re:Difference between Palladium and TCPA

[Glock27]

What TCPA will do, is enable sites on the Internet to not allow you to read the data they give out, unless you are running an operating system that is user hostile and DRM friendly (and not in the "this site doesn't support mozilla" fashion, which can always be hacked around, but in a cryptologically safe fashion).

I don't think this is right, from what I know.

I think the issue is simply "known identity". These initiatives will (finally) provide a standardized, painless, secure mechanism for user/computer authentication. Hardware accellerated encryption is also a GOOD THING.

There are other issues with media playback, but I don't think they're much worse than what we face right now with Windows Media Player. [As an aside, I must say it was a positive move that Micorsoft released their video format as an open standard.]

Furthermore, TCPA should provide the underpinnings for efficient, secure filesharing, er, groupware software.

Am I completely confused?

I think no matter what else, interesting times lie ahead. Remember the old Chinese curse.

Re:Difference between Palladium and TCPA

[swillden]

What TCPA does is sign a hash of the OS that is loaded with an "endorsement key", embedded in the TCPA by the vendor and unaccessible to the user.

This is incorrect; I don't have time to explain what a TCPA-compliant TPM does, but you can find out all you'd like to know here (look at the section entitled Documents"). In particular, this document.

However, although your description of the mechanism is incorrect, your explanation of the potential effect is right. Among other things, the TCPA makes it possible for a user to generate a public/private key pair whose private key is only usable by the system when it's running a particular set of software (BIOS/OS and selected applications), and is never accessible at all. Given that capability, it is therefore possible to get the public key certified by some third party and then to use the private key to authenticate the boot configuration.

After that has been done, it is then possible for someone to send you data that is only decryptable when you have booted into a certified configuration.

But who would do the certification? And how would they know what the system is running when they certify it? Keep in mind that it's not possible for, say, MS to "certify Windows 2005", the certification is specific to each and every machine. There's really only one way for the scenario you described to work on a large scale, and that's for the hardware vendors who pre-install software to have the TPM generate a key pair and certify it for use by third parties, like web sites.

TCPA is a very useful security tool, but it is possible for it to be abused, given collusion between manufacturers, operating system vendors and content providers.

What we need to avoid all of this is strong digital consumer legislation that requires that every digital rights management system include escape hatches to allow for Fair Use, format shifting, platform shifting and copyright expiration. That would prevent the abuse of the technology without taking away the usefulness of TCPA.

Fat chance.

Re:Difference between Palladium and TCPA

[Anonymous Coward]

The grandparent poster was correct. TCPA and NGSCB can authenticate the trusted computing base (OS and nexus computing agents) to other systems. Yes, users will probably have to authenticate themselves to the OS and NCAs, but that's not the primary "contribution" of TCPA and NGSCB.

If a system cannot prove the identity of its trusted computing base, then other systems may choose to not interact with it.

Re:Difference between Palladium and TCPA

[Alsee]

TCPA is a neutral technology. If the TCPA just sits on the board unused, you'd never know it's there at all.

While you are right that you can leave it completely unused, you are incorrect about it being a "neutral" technology.

On the other hand, if the user has the signing key (I say user, since in reality, whoever has the signing key is the owner), TCPA permits (but does not assure) user friendly, outsider hostile strong system security.

TCPA FORBIDS THE OWNER OF THE MACHINE from ever having access to his own keys and his own data. The sole purpose is to secure the machine AGAINST the owner.

This design specification is NOT NEUTRAL. There are absolutely NO possible pro-owner uses for it. Every single claimed benefit to the owner could be accomplished just as well with an idential system that gave the owner full control and full access to his own encryption keys and data.

This design requirement is purely a weapon against the owner of the machine. TCPA contains a purely malicious element. Every single argument defending TCPA fails on this point. They could very easily drop this malicious design specification from TCPA and make a non-malicious system, but they will never agree to do so because this malicious feature is the very heart of TCPA and it is the very reason they are developing and pushing TPCA.

-

Re:Difference between Palladium and TCPA

[Anonymous Coward]

The Palladium system is like a system of millions of trapdoors where each trapdoor only is permitted the access to the rats of HacerCorp, and later escaping from the victims along of the kilometers and kilometer of long pipes.

RaTs, rats, rAtS, RatS, rATs, .. RATS!!!

open4free

Re:Difference between Palladium and TCPA

[SiliconEntity]

Like many things, TCPA is a neutral technology. If the TCPA just sits on the board unused, you'd never know it's there at all. With Palladium, your system will be actively user hostile and RIAA/MPAA/MS friendly.

That's a false distinction. You can leave Palladium turned off as well. It just means that you won't be able to run applications that require Palladium. But it's the same with TCPA, you can leave it off but then you won't be able to run applications that require that technology.

And Palladium is no more RIAA... friendly than TCPA. Both systems provide the same basic functionality, of encrypting data such that it is locked to a given software configuration, and allowing software to prove its configuration to remote systems. This is what will allow a server to restrict downloads to software components that will only support DRM.

Now, in practice, Palladium is of more interest to the content companies because it is going to be so much more widely deployed than Linux+TCPA. The main TCPA (now called TCG) applications will be on non-desktop platforms like cell phones and PDAs. But both are variations on the same Trusted Computing theme.

Re:Difference between Palladium and TCPA

[Anonymous Coward]

shut up Alsee. No one cares what you think about TCPA. Fact is that you are completely off-base, as shown in a previous discussions about TCPA. Just shut your trap and leave. If you really did read all those specs, and you had a real argument, the world would know about it by now. Of all the talk against TCPA, your argument is never mentioned. Odd isn't it? You would think that if you had a real argument, some tech-minded writer would pick up on it in an instant. Of course, if you did read up on the specs, you wouldn't have been able to post your 3500 comments to slashdot. We doubt you actually know what you're talking about.

Re:Difference between Palladium and TCPA

[SiliconEntity]

Palladium, on the other hand, uses similar technology to make sure that the user does not do anything else than what is allowed by content owners. In that case software openness is impossible - otherwise you could do some harm to their system - attacking from inside...

Then why does Microsoft say, in their FAQ:

Q:How can anyone be sure that the nexus and related components do exactly what you claim they do?

A:Microsoft will make widely available for review the source code of the trusted computing base so it can be evaluated widely and validated.

According to your theory, this kind of openness would be incompatible with Palladium. In fact, you are wrong, and Palladium's use of hardware based security allows it to open its software for inspection without fear of security risks.

Re:Difference between Palladium and TCPA

[sjames]

That's a false distinction. You can leave Palladium turned off as well.

You CAN leave it turned off for now. Given the history of MS, and the intent of Palladium that's hardly an adequate guarantee since it is also possible to remove that option in the future.

The distinction lies in what happens if yoiu turn it on. If you own the root keys for the TCPA chip, you can turn it on and use it to assist you in securing your computer from unauthorized access. Note that it only assists you, it is not a silver bullet. At that, the only real protection it provides that doesn't exist now is that it prevents a style of attack where someone temporarily gains physical access to your machine, replaces your kernel with theirs, and then waits for it to sniff the key to your encrypted filesystem.

On the other hand, Given the promises that MS is making, we may deduce that their model can only work if the end user does NOT have the root keys to the system (otherwise, they would substitute their own key for MS's, and use hacked versions of the apps). That is why I feel justified in saying that Palladium is user hostile by design where TCPA is neutral.

Not the right idea...

[hanssprudel]

We want to fight Palladium by fighting acceptance of the idea that the computer should control the user and how he can access the data on his own machine, NOT by developing something functionally equivalent that happens to run under Linux.

Building a DRM system of our own, even if it is open and standards based, just strengthens the paradigm that will leed to an Internet where no data can be accessed as plaintext, applications that are allowed read data have to be accepted and certified by the media industry, and computers exist no longer to enable, but to control, their users.

Please protest against Palladium, TCPA, and all the other DRM proposals by refusing to have anything to do with them: not by strengthening their hand.

(And before somebody replies that TCPA isn't about DRM: Bullshit! Look up what an "endorsement key" is in the TCPA vocabulary.)

Re:Not the right idea...

[amcguinn]

Unfortunately, this kind of thing is valuable in some specialised areas. For high security systems, you want to know that only certain approved code can run.

What we care about is the preservation of general-purpose computers controlled by the user. If we aim to ensure that all computers are controlled only by the user, we will fail, and fail badly, because having, say, a firewall that cannot run introduced code is something so useful that we will not be able to prevent it.

I have hope: firstly, the overhead of trying to deploy this over a large office PC system (the main buyer of general-purpose PCs), will be too high for the benefits.

Secondly, the value of a general-purpose computer that will easily run new software is so high even for the ordinary home user that they will not be entirely replaced by DRM-enabled home entertainment consoles.

It is possible (but unlikely) that this infrastructure will eventually reach the **AA goal of preventing copying of their products. I can live with that provided that our ability to write software for our own computers isn't collateral damage.

Re:Not the right idea...

[hanssprudel]

The specialized areas thing just doesn't hold up. I have yet to see a single example of this that couldn't be solved by current hardware. A lot of people talk about company employees: but few employees have root on their computers anyways, so what is the point with the TCPA chip?

I'm at work right now, and since my local workstation is a Sun Ray I don't even have physical access data in ways that the operating system and application will not allow me (since they all run on a server somewhere). Why would TCPA be necessary to control what I did with my employers documents, instead of just software?

Even IBM admits that TCPA chips can be circumvented by hardware hacks (expect modchips to start appearing), so it can not be used to secure valuable information. The only logical purpose for this technology is to use it on home users, where access to mod chips is limited by laws like the DMCA.

It is possible (but unlikely) that this infrastructure will eventually reach the **AA goal of preventing copying of their products. I can live with that provided that our ability to write software for our own computers isn't collateral damage.

It is not the ability to write our own software that we will be sacrificing, it is the ability to use that software to communicate with the world. Once the TCPA infrastructure is there, the temptation to use it will be to strong to resist:

- eBay will be able to lock out all but some verified list of applications from accessing auction data, so that application to raise bids at the last minute can't be used.

- Microsoft recently kicked off other application from their IM system for "security reasons". As it stands now, this can be hacked around, do you think they'll hestitate to use TCPA to make that impossible? You think AOL are any different.

- Websites will be able to lock out browsers that can block pop-up ads, or that allow cookies to be cleared, or that lie about themselves in the User-Agent string.

- Games will be able to lock out modified versions.

- Given the common confusion that TCPA is about "security", how long do think it will be until your bank starts requiring it?

I could go on and on. The acceptance of TCPA spells the end of the open Internet, and the beginning of a closed network, where all but a few applications are locked out.

I know what I'll do. Whatever it comes to, I will not have a part of this, and I will simply refuse to accept having a computer that is hostile toward me. The reason I argue this so vehemently is because I hope it won't be lonely out here...

Re:Not the right idea...

[amcguinn]

The specialized areas thing just doesn't hold up. I have yet to see a single example of this that couldn't be solved by current hardware. A lot of people talk about company employees: but few employees have root on their computers anyways, so what is the point with the TCPA chip?

I don't have root on my win2k PC right now, but I've got a tomsrtbt floppy in my jacket pocket which works just fine.

Now, if the company was prepared to make the large investment in setting up a full TCPA-style architecture to stop me doing that, it would be prepared to make the much smaller investment in ripping the floppy drive out of my PC. As I say, I don't think the ordinary office desktop is a useful area for this.

I think real uses for this are very rare, just as PCs which are configured by their adminstrators to really lock down what the users can do are currently very rare. But they exist.

I know what I'll do. Whatever it comes to, I will not have a part of this, and I will simply refuse to accept having a computer that is hostile toward me.

Me too. But I think most of the world will be with us, not because they agree with our principles, but because the immediate, practical benefits of being able to run any piece of software on their PC without it being approved by any third party are far too great to sacrifice for the miniscule benefits (in normal circumstances) of "Trusted Computing".

Re:Not the right idea...

[hanssprudel]

I think real uses for this are very rare, just as PCs which are configured by their adminstrators to really lock down what the users can do are currently very rare. But they exist.

An astroturfer lectured me a few months ago that it was important for "Brazilian voting machines", but even in such cases I cannot buy it. If you want to lock down a machine, don't give out root, lock down the BIOS, and get a solid case with a good caselock. Sure, the data can be retrieved in this case with a crowbar and a BIOS reset, but TCPA chips can be circumvented as well, just by slightly more sofisticated methods.

Me too. But I think most of the world will be with us, not because they agree with our principles, but because the immediate, practical benefits of being able to run any piece of software on their PC without it being approved by any third party are far too great to sacrifice for the miniscule benefits (in normal circumstances) of "Trusted Computing".

Optimism is good as long as it doesn't lead to complacency.

Re:Not the right idea...

[Anonymous Coward]

There is no quick fix for security, it's a process, therefore anybody ramming TCPA down my throat is untrustworthy. I use online banking at work (small company), the website is designed for IE and requires javascript. It's clear that this bank would prefer to give it's users dancing, flashing flying pigs rather than security. If anybody thinks I'm going to let this bank dictate my companies security policy, think again!

Re:Not the right idea...

[paulhar]

Why this may or may not be a worthy cause I don't believe it's got a fundamental weakness. While each application relies on and uses the data it receives it may still take actions that weren't intended by the designer of the system.

Most "office" type applications execute the data directly (e.g. macros, vbscript, etc) and it would be a large step backwards to disable this even for the increase in security it would bring. We could turn it all off today (java, jscript, vbscript, macros etc) and we're still vunerable to bugs that get exploited.

Tricking "signed" applications to doing things they aren't supposed to do was demonstrated to great effect with the XBox hack.

Re:Not the right idea...

[bruthasj]

Question: Do you currently protest GPG signatures and encryption algorithms? Where do you draw the line between what *you* want to encrypt/control and what *you* want *others* to encrypt/control? Or do you want to pull an RMS and have no passwords to protect your systems, no security to lock your documents that you created and no rights to control stuff that you created? Shouldn't we let people have the right to handle guns and the right to handle encryption/document rights/system verification in anyway shape or form they please? Whether that be individuals, groups, churches, cults, governments, corporations, criminals, gangs, ACLU, EPA, Green Peace or whoever else!

Everything has an avenue of abuse, but that does not mean scrapping the whole thing because it's got a hole for possible misuse. I mean, look at another case in point: P2P networks. Do we sue the thing out of existence? Or do we fix the violators? What are the definitions of violators?

It's all nice and rosy to flat out and protest something that's "unknown", but the fact is the technology is here and big players are pushing for its existence. Unbelievers in the technology will always be a small ragtag of protestors holding up placards in front of large corporation buildings towering the skies of Redmond, WA.

Don't get me wrong, I hate Windows and I'm a Linux zealot, but I just cannot take your protest position at this time. Sorry.

Re:Not the right idea...

[Simon Brooke]

I could go on and on. The acceptance of TCPA spells the end of the open Internet, and the beginning of a closed network, where all but a few applications are locked out.

I know what I'll do. Whatever it comes to, I will not have a part of this, and I will simply refuse to accept having a computer that is hostile toward me. The reason I argue this so vehemently is because I hope it won't be lonely out here...

I don't believe we (for i'm entirely with you) will be in the least lonely. The open Internet is valuable enough to enough people and organisations that there will be a continuing, mass, market for general purpose computers and for communications systems that allow them to intercommunicate. These may no longer be the machines used by Joe Average, but I think you can be reasonably comfortable that they will continue to be available.

Furthermore, those of us who want to use them are the geeks, and frankly we can carry on using them even if the commercial environment becomes very hostile, both because we have the ability to keep current generation machines running (if new machines come to be locked down so tightly we can't use them) and because we can establish channels of reliable communication over any medium that provides bandwidth.

Re:Not the right idea...

[hanssprudel]

I don't want to sound hostile, but I think you have misunderstood what TCPA, Palladium, and DRM is all about.

I'm a big fan of privacy and cryptography. I implemented entire PKI systems, and I have a masters degree in mathematics, so I even understand a little about why it works. Not only do I not protest against GPG and personal encryption, I use it as often as I can and encourage others to.

There is no contradiction between supporting encryption and disliking DRM. DRM may use encryption, but totalitarian regimes use movies - that doesn't mean you have support totalitarian regimes to like movies.

TCPA is not about encryption, TCPA is about DRM. People who want to encrypt data for themselves, or between a group of people do not need tamper proof hardware chips on their motherboard. DRM systems, which are used not to keep data secret, but to control what people can do with the public data they have access to, do.

Programs like GPG uses encryption to keep something secret when all the parties to the encryption want it secret. DRM uses encryption to the keep the actual data secret from one of the parties, so that he can be subject to his computer regarding what he can do with the data in question. There is little or no intersection between the two.

Re:Not the right idea...

[OeLeWaPpErKe]

Ok, you want it to run your programs as trusted ? You can't, which is the whole problem with palladium.

Re:Not the right idea...

[Afty0r]

- eBay will be able to lock out all but some verified list of applications from accessing auction data, so that application to raise bids at the last minute can't be used.

This is somehow bad? If this happens, auctions will work the way they are intended to (and the way they work best). Fairer prices for all.

- Microsoft recently kicked off other application from their IM system for "security reasons". As it stands now, this can be hacked around, do you think they'll hestitate to use TCPA to make that impossible? You think AOL are any different.

They are running the chat servers, it's up to them what data they send out and receive. If this happens, more people will migrate away to open chat networks.

- Websites will be able to lock out browsers that can block pop-up ads, or that allow cookies to be cleared, or that lie about themselves in the User-Agent string.

This is a good thing - content owners can choose to send away potential visitors who would not see pop-up ads. In time, sites which do not use popup ads will become more common and more succesful.

- Games will be able to lock out modified versions.

This is an exceptionally good benefit. A really strong way to prevent people cheating in online games.

- Given the common confusion that TCPA is about "security", how long do think it will be until your bank starts requiring it?

I can't see any negative consequences of this?

Re:Not the right idea...

[bruthasj]

> I think you have misunderstood what TCPA, Palladium, and DRM is all about.

Other arguments other than my capability to comprehend are more appropriate, as you relate further in later paragraphs. I do understand what these are all about and my questions still remain.

> DRM uses encryption to the keep the actual data secret from one of the parties, so that he can be subject to his computer regarding what he can do with the data in question.

You've said this quite well. However, my question remains ... why are we protesting the vehicle rather than its passenger? Why do we want to banish P2P networks because of misuse? Why do we want to banish TCPA because of potential misuse? Either one is fine, a vehicle to convey information in either a wildly unrestricted manner versus a wildly restricted manner. The key point is the creator decides what goes: whether its open or proprietary. Of course, I'm a fan of open 'data', but I cannot protest and remove rights of those who want to close their own data.

So, my view is let's protest the data, the passenger, rather than the vehicle.

Re:Not the right idea...

[hanssprudel]

My point was exactly that a lot of people (including you apparently) would find these applications favorable. So once TCPA is in place, we can expect the Internet to begin moving toward a closed system where all these things are possible.

So what will this mean?

It will means that innovation will be strangled, that new program features will be decided by lawyers on a comittee. Remember the RIAA's stated model regarding P2P software: you cannot write it without our permission. Welcome to that world.

It means that the open source development model, which relies on the usability of thousands of versions of the same program will be destroyed. And since the people doing the signing will be the commercial software vendors it seems doubtful they would consider signing even a single version of an open source app for free.

It means that ability to communicate and publish data will be recentralized through the signature authorities. It means the ability to censor every copy of a piece of data with the press of a button. Think that wouldn't happen? Think again: once the courts find out is possible, they will start with something that nobody can defend, like a piece of child porn or particularly egregious slander. Before you know it, it will be leaked scientology papers, and then any criticism against them.

It means the end of anything close to balance regarding in copyright law. Copyright law will become redundant, because all data will be encrypted and completely at the mercy of the publisher. The goal of ending the public domain once and for all will be achieved.

It means that people who decide that they own their computers, and refuse to submit to their computers authority over them, will be locked out from the Internet, and successively from society.

Re:Not the right idea...

[hanssprudel]

Because the only purpose of DRM is the control the user. This is unethical in and of itself, regardless of it's purpose. A computer program is responsible for acting in the interest of it's user the same way a doctor is to a patient, or a lawyer is to his client. Machines should be subjects to people, not the other way around.

I have never argued for forcing anything on those who wish to close their data. They can do whatever they want. I argue two things (and only the first in this particular thread):

1) People should not use TCPA, they should not accept it's presense in their hardware or software, and unless they actually want a closed Internet they should not be developing for it (like the Dartmouth people).

2) Our governments should not be making laws that remove OUR RIGHTS to hack through these system on our own machines, or to make them mandatory.

The people who do wish a closed network can knock themselves out writing DRM systems as far as I am concerned. I will continue arguing as loudly as I can that people should not use them.

Re:Not the right idea...

[sketerpot]

Same here. And if I want to lock down a computer, I'll use grSecurity on Gentoo and probably some chroot jails.

Re:Not the right idea...

[sketerpot]

This is a good thing - content owners can choose to send away potential visitors who would not see pop-up ads. In time, sites which do not use popup ads will become more common and more succesful.

Imagine the mess that would cause. There are already far too many "professionally" designed web sites that refuse to work without Internet Explorer, such as Amano's World. Can you imagine the nightmare for users of other browsers if IE became actually required? What about proxy servers? I currently use bfilter, which blocks out the worst of the web before it gets to me. I imagine that it wouldn't be allowed. So we limit proxies to... whatever microsoft provides? That and approved versions of squid if these "control the way you look at my web site even if it is completely anathema to the web's philosophy" people are feeling generous. And what about plugins for proxies that have such an architecture? Would it be necessary to disallow third party plugins/modules/whatever, therefore destroying the hard-earned flexibility that programmers are always striving for?

Actually, I think that alone would pretty much kill those W33 0wn j00 web sites. Still, I much prefer to give power to the users, since that's what I am. Control freaks give me the willies.

Re:Not the right idea...

[amcguinn]

Indeed. And it's the reason why user-hostile terminals will never be able to replace general purpose computers.

In the large financial company I work for, a proportion of the software on the desktop is in-house developed. Will the corporate IT department accept a windows upgrade that would mean every new release had to be submitted to MS for signing? Will they accept an office upgrade that would mean they can no longer exchange data between standard and in-house applications? The PC has got to where it is because of its flexibility, and that is too valuable to be abandoned.

For the home, the situation is more dangerous. People already listen to CDs on CD players, watch DVDs on DVD players, and play games on consoles. DVDs and some games are already DRM-protected with hardware support, and the rest are likely to go that way. However, the general-purpose computer still has enough different uses that it is likely to survive in the domestic arena, even if some households will have user-hostile devices instead.

The big danger suggested by hanssprudel in his intelligent comments is that general communication channels like the web will be restricted to user-hostile platforms. I think that is unlikely. The disadvantage of a user-hostile platform (to a naive consumer) will be that it will not be able to keep up in software terms with a platform for which anyone can release applications. The advantage will be that it will be able to play DRM-encoded content like CDs, but I think this role will be taken over by other appliances; people will prefer to have a real PC and a DRM-CD player than a crippled PC that can play DRM-CDs. Note that a DVD player currently costs about the same as two DVDs, so the cost of having two boxes isn't going to be the decisive issue.

The final point is that it won't work. The X-box can be cracked because one signed game has a buffer overflow in its "load save game" function. To successfully protect a user-hostile PC running browsers, office applications, and games, every single signed application will have to be completely free of vulnerabilities.

The benefit of the Dartmouth research is that the DRM-CD players might run linux inside. It's not a big deal, but it's good for the manufacturers, it will keep the costs down and reduce opportunites for MS lock-in

Re:Not the right idea...

[omen]

People should not use TCPA, they should not accept it's presense in their hardware or software,

[ Disclaimer, I'm one of the primary developers. ]

It's like a gun, you can use it for good, or you can use it for evil. We are trying to use it for good, to help the owner of the computer protect their computer from outside attacks. TCPA != DRM.

I would recommend you read the white papers linked on the http://www.research.ibm.com/gsal/tcpa/ site. They have quite a bit of insight.

Omen

Re:Not the right idea...

[Anonymous Coward]

I think you're absolutely right, but I also think the flip side of resisting DRM and similar junk is the failure of the commercial entities and government to perceive that what they are encountering is in fact resistance.

Take, as a very easy example, CD sales. The RIAA says they're down because of file-sharing. Media and government seems to believe this. But what percentage of the downward slide is due to people saying, I'm not gonna buy those things because of XYZ, I'm resisting? That percentage is neither being quanitified nor widely recognized.

There are countless examples. I haven't bought a DVD player, and have never bought a DVD, because I would miss being able to easily copy movies like I can do so easily now with my VCR. But do the companies realize that there are people out there like me refusing to buy their new garbage? Or even care?

Re:Not the right idea...

[hanssprudel]

User hostile chips on the motherboard are not needed to secure computers.

All you are achieving is legitimising a technology which is only needed for what you yourself describe as "evil". Please stop and think about what you are doing!

Re:Not the right idea...

[Minna Kirai]

Secondly, the value of a general-purpose computer that will easily run new software is so high even for the ordinary home user that they will not be entirely replaced by DRM-enabled home entertainment consoles.

The ability to quickly download and run a new program is valuable. However, DRM can be implemented in a way which is mostly compatible with that ability. This unfortunately means that we cannot depend on market pressure to protect us from the spread of hard DRM.

It is already a recommended software engineering practice to use system libraries to access data and to run new programs in unpriviledged sandboxes. The natural extension of those techniques to DRM will handle 95% of a typical user's need to run custom software.

Here's how it might work:

1. You get a computer with a DRM chip that'll only load a trusted OS: either Microsoft(tm) Windows(r), or RedHat Linux 12.1 (Redhat has no choice but to cooperate with DRM proponents or go bankrupt). That OS, in turn, will check that executables are certified to protect any proprietary data they load.
2. 
   
   You're a power-user, so you occasionally download new programs. And you're a programmer, so you occasionally write your own. Many of the executables you download and 100% of the ones you write will be flagged by the OS as untrusted.
   
   Untrusted programs can be run, but only in a virtual machine "sandbox" type environment. They can't access hardware or filesystems at a low level. An untrusted program can load unprotected files, display data onscreen, and also save unprotected files. But if it tries to load a protected file (something with a "copy-protect" flag set), then the OS cripples the program. It no longer has any ability to save files to disk or to use a printer. It certainly can't send network packets. Even screen-dumps and vidcap won't work on the application. Maybe it can send data to other programs (with copy&paste or a similar mechanism), but any recipients will become untrusted and face the same restrictions.

In a system implemented as I described (or in several possible variants), the average consumer would still get most of the benefits of running custom code. She could download Bejeweled to play a game. She could run an amortizer plugin over financial data, or an animated filter on a WMA song.

But you've still lost the ability to execute a fully-generic program that gives all data-processing authority to the local user. Will the public care about that loss? I can't see why it'd bother them.

Re:Not the right idea...

[Minna Kirai]

Now, if the company was prepared to make the large investment in setting up a full TCPA-style architecture to stop me doing that

It won't be a large investment. Or at least, it won't look like a big investment until we're several years down the path and in too deep to back out.

The initial capital to deploy DRM will be supplied by corporations with a long-term interest. This means *AA somewhat, but more directly computer corps like Intel and especially Microsoft(tm).

Primarily, Microsoft and Intel will work together to get DRM into the next generation of motherboards, with the 2006 revision of Windows(r) as the first trusted OS. Even though big corps like IBM will be able to market signed Linux distributions, that change will help Microsoft (and other established industry-leaders) by strenghtening barriers to entry. The development of Linux will be slowed because unfunded amateurs won't be able to test their modifications without major sponsorship. (That reason alone is enough to justify Microsoft underwriting DRM deployment)

Once "optional" DRM features are standard equipment on every new PC, it'll no longer be a significant cash investment for a corporation who wants to use DRM to lock their own boxes to an approved list of software.

Re:Not the right idea...

[Minna Kirai]

I haven't bought a DVD player, and have never bought a DVD, because I would miss being able to easily copy movies like I can do so easily now with my VCR.

If you copy movies with a VCR, you must be doing some illegal trick to circumvent Macrovision.

If you get a $25 DVD player for your computer, you can copy movies using an easy trick called DeCSS (look for it on a T-Shirt).

There's no difference between a VCR and DVD in this area, except that DVD players don't include write-equipment by default. But that's a technological restriction, not a legal or copy-protection one. Buying VHS but not DVD is not a way to send the manufacturers any kind of political message.

Re:Not the right idea...

[Minna Kirai]

Tricking "signed" applications to doing things they aren't supposed to do was demonstrated to great effect with the XBox hack.

That's a temporary effect- you cannot rely on that kind of weakness continuing to work.

Current and near-future implementations of hardware DRM will have a weakness in that if an unsafe application is accidently signed, it becomes a permanently exploitable hole on that platform. This has already been demonstrated with a buffer-overrun in a certain James Bond game.

However, highspeed internet access will be eventually be ubiquitious. In 15 years or so, a tiny, low-power chip will get you a 56Kbps connection from anywhere on the planet for a neglible cost. When that time comes, bugs in signed code will no longer be a weakness to hard DRM.

It will become easy to revoke a specific certificate even after the code has been deployed. Before loading any program, the OS will just send a hash-value back to the secure fortress of the original signing authority. If a once-trusted program has been found to be buggy, then the OS will blacklist it from execution until a (certified) patch is applied.

(In fact, an even worse scenario might happen: If the OS ever learns that a program you've been running is exploitable, it could retroactively destroy any files that were written by the program, just in case they had some "stolen" data. Nah, that level of response is too extreme even for the RIAA)

Re:Not the right idea...

[Minna Kirai]

a proportion of the software on the desktop is in-house developed. Will the corporate IT department accept a windows upgrade that would mean every new release had to be submitted to MS for signing? Will they accept an office upgrade that would mean they can no longer exchange data between standard and in-house applications?

That's no obstacle to user-hostile DRM. (Read my other comments in this thread for more explanation).

The heart of "hard DRM" is that the hardware, OS, and application all form a chain of trust that will not willingly violate any copy-protection labels applied to a piece of data.

All of the data processed by your company will have flags stored in the filesystem indicating either that it belongs to your corporation, or is unprotected. When a trusted program loads the data, it will correctly propagate that flag to any output files. When an untrusted program loads data, the OS will do that job for it. The program will only be allowed to load files from a single owner in one session, and any output it generates will be stamped with the most restrictive flags from any file it read.

That is, a DRM OS may permit you to run untrusted code, but it will assume the worst and flag any outputs of that program as infringing copies of whatever inputs it had. If you load an MP3 into a custom program which writes the average loudness into a small text file, that output will have the same restriction flags as the original song file. It will only be readable as long as your paid license to hear the MP3 is still in force.

PS. Naturally, an effective DRM implementation also assumes some other changes will be done as a prerequisit. Well-known protections against memory corruption and buffer overflows will need to be added as a matter of course.

Re:Not the right idea...

[Melantha_Bacchae]

A gun may be used with good intentions (to protect), or with evil intentions (to harm), but it can only be used to kill or wound. And if you aren't very careful with it, the bad guy can take it from you and use it on you. Guess what intentions the bad guy has?

Embrace. Extend. Extinguish. Remember those three? Remember the part where Microsoft is the bad guy?

"At this moment, it has control of systems all over the world.
And...we can't do a damn thing to stop it."
Miyasaka, "Godzilla 2000 Millennium" (Japanese version)

Re:Not the right idea...

[Dalcius]

I'm not sure that the sane folks are saying "DEATH TO SECURED COMPUTING" as it has a practical application in locking down very specific systems, but YOU need to be AFRAID of this thing getting into your box. Companies like IE, HP, IBM and the like have the power to put this stuff in there, and as long as most users are happy (believe me, these companies will try to keep it that way), this stuff will roll out without much of a fuss.

Then they can slowly tweak their usage of this technology. Turn the heat up slowly and the lobster won't jump out...

You and I need to be very vigilant to ensure that this doesn't start controlling how we, the normal user, use our own bought-and-paid-for computers. Education is the only way, because of the sheeple don't care, it's going to happen and the DMCA will prevent you from doing much about it.

There are many things to fight for in this world. Since computers are my life, fighting for my right to use my computer as I see fit is important to me.

Re:Not the right idea...

[MenTaLguY]

You've just described label-based MAC, by the way.

Re:Not the right idea...

[SiliconEntity]

The ability to quickly download and run a new program is valuable. However, DRM can be implemented in a way which is mostly compatible with that ability. This unfortunately means that we cannot depend on market pressure to protect us from the spread of hard DRM.

Your statement is right but your implementation is all wrong. The way it actually works is that each program is able to encrypt its data so that only that program, or other programs signed with a per-program key, can access that data. And likewise, programs can authenticate themselves on the net as being signed by a particular key.

The point is that there is not one "magic" key, but rather each application or manufacturer or developer who wants to use this technology creates his own key. That key controls access to the data for that application, and programs signed with that key can prove their signatures to each other.

In this approach, there are NO LIMITATIONS on the use of ordinary applications or what developers want to do. You can write and run any software you want. But your software won't be able to access your Quicken billpaying database, because that is encrypted using a key that only Quicken-signed software can access. And your software won't be able to display your downloaded movies, because those were saved by a video program certified by the MPAA and encrypted using their own key.

This is the basic idea behind Palladium (NGSCB) and TCPA (TCG). They retain backwards compatibility, but add a new capability for program-specific encryption and remote attestation.

Re:Not the right idea...

[SiliconEntity]

In the large financial company I work for, a proportion of the software on the desktop is in-house developed. Will the corporate IT department accept a windows upgrade that would mean every new release had to be submitted to MS for signing?

Christ, how long will it be before this lie is put to bed?

Palladium does not require Microsoft to sign applications! Read the Microsoft technical FAQ: "Anyone can write an application to take advantage of new APIs that call to the nexus and related components without notifying Microsoft or getting Microsoft's approval."

This has been reiterated over and over and yet the message doesn't get out. The belief that Palladium will only run Microsoft signed code is by far the most common misconception about the technology.

There may be good reasons to oppose Palladium, but let's base our reasoning on truth rather than lies. And by the way, you might want to think about who told you this lie, and ask whether they had an agenda of their own. Maybe the source of this misinformation is not as trustworthy as you think.

Re:Not the right idea...

[Minna Kirai]

Your statement is right but your implementation is all wrong

I was describing a possible extension to the normal DRM scheme which could solve some of the problems amcguinn cited as to why DRM will never succeed in the marketplace. DRM-implementors don't have to do it my way- but if they don't, they'll lose some customers (maybe not enough for them to care)

But your software won't be able to access your Quicken billpaying database, because that is encrypted using a key that only Quicken-signed software can access.

In the hypothetical system I was describing, the authors of the DRM OS have created additional safeguards that will allow user-authored (or otherwise untrusted) programs to access some Quicken data, without being able to completely liberate it. Removing that limitation will make power-users like amcguinn more likely to buy a DRM-based PC.

Assuming that the vendor of both the OS and Quicken are in agreement, they can allow Quicken to output data in an unencrypted format. But the OS is trusted to not obey the user fully. It will manage that data and only allow limited operations on it. Any program which attempts to load the data will be placed in a restrictive sandbox, where it can perform some kinds of analysis and display, but not output anything to a remote computer by using a hard disk, network card, or printer.

With a system like this, it's still possible for user to run an unauthorized 3rd-party program to do a calculation on data stored in Quicken. But the 3rd-party program cannot be used as a bulk way to strip the protection from a mass of files.

Re:Not the right idea...

[riptalon]

a firewall that cannot run introduced code is something so useful that we will not be able to prevent it

This is true but you don't need TPCA to do this. Putting this functionality at the firmware level is sufficient to achieve what you suggest. In fact I would be suprized if it wasn't done already by specialized vendors. There is a difference between not trusting the computer user and the owner. An organisation can have firewalls with secure firmware such that no one can load any old software on to them without the right codes or keys (without pulling the battery on the CMOS, which is good enough, especially if you have a lock on the case). Putting the functionality in hardware is only useful for stopping the owner of the computer from using it anyway they want.

There is no valid security reason for TPCA. All security problems to do with stopping users from doing stuff the owner of the computer doesn't want done can be handled at the firmware and OS level. This sort of hardware solution is only necessary for DRM where even the owner of the computer isn't trusted. TPCA/Palladium is likely enough to spread through the installed base, leveraged by Microsoft's market share, without any help from the free software community. If it succeeds then free software is dead in the long term, so any cooperation with it is akin to attempted suicide.

Re:Not the right idea...

[Alsee]

[ Disclaimer, I'm one of the primary developers. ]

Excellent. First let me point out that I have read those white papers and I even had a breif E-mail exchange with the author. I have also read portions of the highly technical TCPA design specifications itself.

I would like to see you justify the TCPA design specification that the owner of the machine is forbidden to know his own encryption keys. Every single claimed benefitr in the Why_TCPA whitepaper can be acheived just as well by an identical system that DOES give owner of the machine access to his own encryption keys. The author of Why_TCPA did not dispute this.

Why_TCPA completely fails to justify the central TCPA design requirement.

I would like to see you justify the design specification of "non-migrable data". The TCPA specificly states that it MUST NOT be possible to move this data from one system to another even with the active cooperation of the the owner of the machine and the owner of the data. The only possible purpose for the this TCPA design specification is for the purpose of of securing the computer against the owner and for DRM.

The TCPA_Rebuttal fails because it does not address these valid criticisms of TCPA. The TCPA_Rebuttal directly dissmisses DRM arguments, yet DRM is the only possible basis for for the TCPA design specifications.

I suspect the author of these white papers was intentionally dishonest, though to give him the benefit of the doubt perhaps he simply never considered the possibility of a substantially identical system that did grant the owner access to his own keys. When I suggested this to him his ony response was to suggest that denying the owner access to the keys could secure a stolen lap-top against a thief by denying the thief access to the keys as well. This fails on two points:

Firstly he is contradicting himself - in the Rebuttal he claims that TCPA is not designed to be secure against physical access. If isn't supposed to be secure then his "theif" argument is disingenuous, the laptop would not be secure against the thief anyway. And if TCPA *is* supposed to be secure against a thief then he is invalidating his own evidence that TCPA is not designed for DRM.

Secondly it is pefectly posible to give the owner of the machine his encryption keys while still denying the keys to a theif.

At this point the author of the TCPA white papers did not respond. He did not dispute my criticisms of TCPA. He only offered a weak "anti-theft" argument.

It's like a gun, you can use it for good, or you can use it for evil.

The design specification is malicious. TCPA is designed to secure the machine against the owner. You can get all of the claimed benefits of TCPA and eliminate all of the valid objections to TCPA simply by giving the owner of the machine access to his own keys. They refuse to do so for "evil" reasons.

You can claim a cake can be used for good or for evil, the cake itself is evil so long as the baker REQUIRES that all cakes must contain a poison pill.

-

Re:Not the right idea...

[Anonymous Coward]

shut up Alsee. No one cares what you think about TCPA. Fact is that you are completely off-base, as shown in a previous discussions about TCPA. Just shut your trap and leave. If you really did read all those specs, and you had a real argument, the world would know about it by now. Of all the talk against TCPA, your argument is never mentioned. Odd isn't it? You would think that if you had a real argument, some tech-minded writer would pick up on it in an instant. Of course, if you did read up on the specs, you wouldn't have been able to post your 3500comments to slashdot. We doubt you actually know what you're talking about.

Re:Not the right idea...

[Anonymous Coward]

Re: illegal Macrovision trick ... um, no, my VCRs are perfectly legal and were bought pre-Macrovision.

Re: DeCSS, of course, but you missed where I said I want to be able to do this copying "easily". Computers are another story, but I really don't feel like hacking my TV and its related equipment. I don't need or appreciate the convergence between computers and TV - TVs are just dumb stupid passive output devices and copying a program should be as easy as using my VCR.

Re:Not the right idea...

[Alsee]

Why do we want to banish TCPA because of potential misuse?

Because TCPA is specificly designed for the purpose of misuse.

Aside from DRM and denying people control over their own computer, there is not a single thing you can do with TCPA that you could not do just as well with an identical system that did NOT deny people access to their own keys.

Any system that denies people access to their own keys and denies them control over their own computer is a malicious system. I will give TCPA my full supoort the instant they drop this aspect. They will never do so because their primary motivation is for DRM and stealing control over people's computers.

-

Re:Not the right idea...

[Anonymous Coward]

shut up Alsee. No one cares what you think about TCPA. Fact is that you are completely off-base, as shown in a previous discussions about TCPA. Just shut your trap and leave. If you really did read all those specs, and you had a real argument, the world would know about it by now. Of all the talk against TCPA, your argument is never mentioned. Odd isn't it? You would think that if you had a real argument, some tech-minded writer would pick up on it in an instant. Of course, if you did read up on the specs, you wouldn't have been able to post your 3500 comments to slashdot. We doubt you actually know what you're talking about.

Re:Not the right idea...

[Anonymous Coward]

oohh... someone's a little hostile... Why don't you shut up? Alsee's far more interesting than you.

Re:Not the right idea...

[Anonymous Coward]

luddite

Since this is Slashdot...

[Capt'n Hector]

*inserts obligatory SCO commment about 'compromised software'*

Great business plan!

[Anonymous Coward]

Who will be the first to start selling mod chips for pc computers?

Re:Great business plan!

[Minna Kirai]

Anyone who wants to win a 10 month, all-expenses-paid to gorgeous Club Fed in Guantanamo Bay, Cuba!

This works out great for the suits

[TerryAtWork]

as part of their plan to seize the internet and digital stuff in general, they get to hitch Linux up like a draft horse to do it.

Something that was supposed to set computers free is being used to help lock them down.

Trustworthy computing

[sneakybilly]

I love this bit from the microsoft ngscb pagen "Data can be protected with a secure pathway from the keyboard through the computer to the monitor screen, preventing it from being secretly intercepted or spied on" Yeah like this is a major security problem with current day computing. I've always wondered if my information is secure between my keyboard and the monitor :)

Re:Trustworthy computing

[hanssprudel]

It's not meant for you, none of this technology has anything to do with _your_ security. These products are intended to protect people from you, specifically, in this case, the movie industry who don't want you re-recording movies from the monitor cable.

Re:Trustworthy computing

[AYeomans]

Are you sure you don't have one of these keyboard sniffers connected by your employer / family?

Re:Trustworthy computing

[Anonymous Coward]

You're right - this technology isn't meant for people who don't care about security. It's meant for governments, military, medical and financial service companies, for who keyboard sniffing and tempest monitoring *is* a valid security concern.

Re:Trustworthy computing

[quantum bit]

You're right - this technology isn't meant for people who don't care about security. It's meant for governments, military, medical and financial service companies, for who keyboard sniffing and tempest monitoring *is* a valid security concern.

And ironically it won't help with either of those. If your keyboard is untrusted (sniffer hooked straight into the circuit) it will still log your keystrokes even if everything on your computer is signed and verified.

Having a secure path between the CPU and the monitor does nothing against tempest. It's the interface between the monitor and the surrounding EM field that tempest snoops on.

Don't forget that LCD monitors are not invulnerable to tempest either.

Re:Trustworthy computing

[SiliconEntity]

"Data can be protected with a secure pathway from the keyboard through the computer to the monitor screen, preventing it from being secretly intercepted or spied on" Yeah like this is a major security problem with current day computing. I've always wondered if my information is secure between my keyboard and the monitor :)

It's not funny. Ever heard of a keystroke logger? What if you're typing a password for your online bill payment service, wouldn't you like to have a secure path from the keyboard to the program? And if your bank software is displaying the account number on the screen, it would be nice if back orifice or some other Trojan program was unable to peek at the video memory. This is the kind of thing that Palladium aims to protect against, in the passage you quoted.

Re:Trustworthy computing

[GigsVT]

The point is that all pathways will be encrypted and digital. All you'd log would be encrypted gibberish.

Re:Trustworthy computing

[scrytch]

> I've always wondered if my information is secure between my keyboard and the monitor

Considering it takes a trip through the potentially keystroke-logger-ridden virus-infested operating system in order to do so, perhaps you should wonder...

Re:Trustworthy computing

[yerricde]

But the difference is that in the Palladium and TCPA models, the owner of the machine cannot decrypt the data stored on the machine. A security model useful for user-friendly privacy but not for user-hostile copyright enforcement would allow the machine's owner to access all keys used to decrypt data stored on the machine.

Re:Trustworthy computing

[yerricde]

It has to become analog sometime, as the human brain cannot readily perceive an encrypted digital signal. TEMPEST attacks work on CRT or LCD signals after they have been converted internally to analog for display use. How does Pd or TCPA prevent TEMPEST (on the display end) or looking over the user's shoulder (on either end)?

Start Song..

[instanto]

Its the end of the world as we know it...

(I could have typed more, but then I would probably owe RIAA 150.000$ per slashdot user who read this)
(all 5 of them since I have a bad karma)

Palladium is actually about security

[Photo_Nut]

Think about this for a moment before you call me a troll, mark this post as flamebait, or bash me for being a MS supporter on the issue. It's not funny, it's serious.

Palladium/TCPA is a security measure, not just a DRM platform. Enabling DRM is impossible in the sense that DRM doesn't cover the analog hole. As long as people have the ability to reproduce video and audio, DRM will only prevent people who do not have other recording mechanisms from copying raw data. Digital cameras get cheaper each day. Multimedia devices are falling in price and becoming higher quality every day. Today I saw a $50 DVD/CD/MP3 player. Star Trek like systems will be here before most of us die of cancer.

Now lets get back to our topic. Security. Palladium. The thing which Palladium prevents is unsigned code from executing. It's literally a form of sandbox for x86 code. Say that you write a program which attempts to install itself into my system registry and that installer mechanism isn't signed, my computer can prevent you from installing software on it. Of course, if I (as the user of the machine) am given the choice, and let you install the software anyway, knowing it is unsigned, then at least I can share the blame for the insecurity.

Bill Gates is no stupid man. It is right that these systems are systems based on trust. If you don't trust Microsoft, it doesn't work. If the magic key-granting-key for granting root keys is ever discovered or hacked at Microsoft headquarters in Redmond, then the game is over. Of course, in the Linux world, that magic key is somewhere else. Maybe there is a new key for each distribution.

Now, I'm not saying that this system doesn't have potential for being abused. If I sign my worm for Red Hat Linux, then the protection system is useless. Worms might still be able to get inside via the older flawed software. Microsoft needs legacy applications to continue its business. The reason that MS owns so much of the computer market is that it had so much of the application share before and it didn't ruin feature compatibility with newer versions, among MS apps and with 3rd parties that were important.

The initial hole in Palladium is the same hole in DRM: In order for it to be successful, it has to work. DRM doesn't work (analog hole, memory and simulation based attacks), and Palladium may make a huge dent in internet worms, but it won't stop Macro Viruses or prevent IE from popping up new windows.

Palladium is one step in the right direction: locking down the OS to only perform installs of "trusted"/signed software. There are several other serious security measures which need to be taken:
1) Buffer Overflow prevention
2) Unsigned Device Driver prevention, and strict certification of Device Drivers
3) Lock-Down of all user and administration activities into appropriate accounts
4) Making all of the above trivial to set up for a newbie

Microsoft isn't much farther along than Linux in any of these areas, but Linux won't gain any momentum among novice users if it doesn't improve in ease of use. The next 4 years should be very interesting in the software market. The industry has matured a great deal recently after its adolescence period/dot com crash.

Re:Palladium is actually about security

[hanssprudel]

Worms work by getting code that is not supposed to be executed to be executed. They do this by finding exploits.

This code is already not supposed to executed, regardless of whether it is signed. Why should adding another reason not to run the code make any difference?

Re:Palladium is actually about security

[amcguinn]

There are two reasons for wanting this in hardware, as opposed to just in the software:

1. To enforce rules that the user can't break ("hostile computing").
2. To prevent the boot loader from being corrupted by malware.

The second reason is a tiny capstone on a pyramid of security that most people haven't built to anywhere near the height where it would be useful. It can be practically disregarded.

All the other things you list can be done without hardware support, and the only catch is that the end user can choose to disable them. Even then, he might need to open up the box to do it. (password-protected BIOS, no booting except from hard disc: most PCs can do that.)

And you're wrong about worms. In most cases, as far as the OS is concerned, the worm isn't running. Some ordinary program (e.g. SQL Server in the case of the slammer worm) is running, but the worm, by feeding it bad data, has caused it to corrupt itself so that it has effectively become the worm. There is no "worm.exe" for a security processor to refuse to run.

Re:Palladium is actually about security

[Ed Avis]

But if you don't want to run a particular program (such as a worm), don't run it. There is no need for all this signature stuff, except to prevent the user from running software of his own choosing.

If you did decide to run only code signed by a trusted key, the only reasonable system would be for the owner of the PC to posess that key. (This could be the company IT department, or the individual user for home systems.)

Re:Palladium is actually about security

[Si]

There is so much wrong with this post I don't even know where to start. Please, tell me you were just trolling.

Re:Palladium is actually about security

[HiThere]

I don't think you're a troll. But I do think that you're remarkably short sighted. Or that you have a naive degree of trust in the beneficence of large corporations.

MS apps are insecure in ways that don't bother MS. Frequently they even use the insecurities as sales points (for the next version ... which they *claim* will fix the problem). It's not insecure in ways that bother MS. Or if it is, those get fixed quickly. Palladium will not be used for the benefit of end users except incidentally. It will be used for the benefit of MS. But the benefit of MS has recently NOT coincided very closely with the benefit of the users.

Now you can, indeed, claim that it *COULD* be used for the benefit of the users. But so could many other techniques that they don't bother to use in that way.

Re:Palladium is actually about security

[Minna Kirai]

Enabling DRM is impossible in the sense that DRM doesn't cover the analog hole.

The technologies being used to enable DRM hardware create user-hostile computers and are a step along the way to plugging the "analog hole". You mention that digital cameras (still or video) are getting cheaper and better all the time. But digital watermarking already exists, and digital shape-recognition is getting better and better. Long-term, the advances in software will overwhelm hardware improvements. Hardware may open an analog hole, but software will close it.

Future scenario:
20 years from now, a friend visits you with a laptop, and he plays music while your webcam dumps his whole visit into a 3 terabyte AVI.

Weeks later, you'll order a few MP8 songs with your credit card. A click-through license agreement gives the publisher certain rights to monitior your compliance. In collaboration with your OS vendor, they transmit a program onto your PC during a routine system update. This program runs automatically during periods of low CPU use and scans your audio data for any patterns resembling something the publisher owns (not just the songs you rented, but anything in their vast catalog). The software is fast, because it only needs to read user-recorded files. The majority of your songs were legally downloaded and have a copy-protect flag, so they can be skipped.

If an unprotected file gets a 98% confidence match on anything they own, it is automatically uploaded to a lawyer on another continent. This man doesn't know what user's computer it came from, and is sworn not to violate your privacy if the file turns out to be anything other than an analog copy of his client's work. After a quick human-verification that the file sounds the same, the publisher's HQ sends an emergency message to both the OS vendor and the FBI. Instantaneously, your computer freezes up to protect evidence, and an arrest warrant pours out of the fax machine of the nearest police department.

Re:Palladium is actually about security

[Anonymous Coward]

No, it tells you when software that you want to run has been tampered with, so you don't run it.

Re:Palladium is actually about security

[Ed Avis]

But whoever has enough access to the machine to change program binaries presumably has enough access to change the key that's used for verification, or to turn off verification altogether.

Some mechanism to check the integrity of code can be useful - we already have something like this with the RPM package manager, for example: it can verify PGP signatures on packages and then rpm --verify checks installed files against a fingerprint. This is not the same as making sure that only signed software can run, regardless of the owner's wishes and with no control over which public key is trusted.

The Amiga connection

[Anonymous Coward]

Could it be that the Enforcer developers didn't know about the classical tool for Amiga, Michael Sinz' Enforcer? It now comes with source, if you haven't noticed.

Re:The Amiga connection

[omen]

[ Disclaimer, I'm one of the primary developers. ]

We were not aware of that project, thanks for the info.

The future is

[instanto]

I cant wait for this to blow up in everyone who supports its face.

They will say now that "its about security" and due to all the recent hype around virii sobig.f,y and u.name.it they will have a lot of cluesless users all around the world - and executives (who are just as clueless - but with "power" and money)) backing them.

One day humanity will look back at the 90s/00s with regret.

The owner of the PC does NOT own the master keys

[NZheretic]

The long term problem with IBM's model of the TCPA is exactly the same with that of clipper chip encryption, the owner of the PC does NOT control the attestation master keys. This leads to the same escrow agent model which is far to open to exploitation by The New American Corporate Soviet.

Name "BEAR" already taken in crypto

[tomstdenis]

See

http://citeseer.nj.nec.com/anderson96two.html

Get a new name people :-)

I suggest

"BRUNO THE CIRCUS BEAR" which is suitable for the frenzy that surrounds "secure" TCPA style computing...

Tom

I'm sorry but totally avoid TCPA

[FeatureBug]

You cannot copy the keys inside TCPA hardware. I'll explain what this means (if you don't like reading about technicalities, just skip to the final paragraph)

Every time you buy a new PC with TCPA you will not be able to copy the old TCPA keys on your old PC to your new PC. This means you will completely lose access to your videos and your music which you legally purchased and used on your old PC. Effectively you have to buy another set of keys to regain access to your videos and your music collections.

TCPA and other DRM technologies are being pushed by the publishing industry and hardware manufacturers like IBM who want to sell more of their hardware equipped with DRM to make it attractive to commercial content locked-down publications.

TCPA means LOCK-down, LOCK-out, LOCK-up enabler. Avoid getting anything with TCPA.

Re:I'm sorry but totally avoid TCPA

[CaptnMArk]

>Every time you buy a new PC with TCPA you will not be able to copy the old TCPA keys on your old PC to your new PC.

This is a complete showstopper, I agree.

Re:I'm sorry but totally avoid TCPA

[omen]

TCPA means LOCK-down, LOCK-out, LOCK-up enabler. Avoid getting anything with TCPA.

[ Disclaimer, I'm one of the primary developers. ]

Score: -3 Mis-informative

You are assuming that TCPA is being used to enforce DRM, and that that is the only valid use of TCPA. Have you looked at what we have done? We are using TCPA, but not for DRM. We are providing a way for the admin to use TCPA to help secure their computer against outside attack. Again, check out the IBM white papers: http://www.research.ibm.com/gsal/tcpa/.

Omen

Re:I'm sorry but totally avoid TCPA

[FeatureBug]

Yes, I've read your group's papers - of solid academic interest. Yes, I believe as do most truly independent observers outside TCPA that TCPA will be used to enforce DRM and in its current for that's going to hurt ordinary people using home computers. Ordinary people can be educated about the true long-term out-of-pocket costs and threats posed by TCPA. No, I didn't say or even assume DRM enforcement is the only valid use of TCPA but unless TCPA is modified to guarantee the endorsement key(s) can always be copied by the current owner of any TCPA hardware , then DRM is the single most important issue with TCPA and the best reason to reject it totally.

What is interesting and not very surprising is that the public supporters of TCPA such as yourself, never try to give a convincing rebuttals for all of the strong arguments against TCPA. That "Score:-3 Mis-informative" you mentioned is actually for you.

Re:I'm sorry but totally avoid TCPA

[FeatureBug]

TCPA will be used as an enabling technology by publishers to lock-down every publication, locking publications to a particular item of TCPA-hardware without any possibility of transfer, locking publications to a particular expiry date without regard to the lawful expiration of copyrights and fair expansion of the public domain, locking publications to a particular person without regard to fair dealing as recognised in law. Of course TCPA doesn't have to be used for DRM enforcement but no commercial publisher would want to use it any other way because it would be less profitable.

In TCPA "hell", people will not be allowed complete freedom to choose which software to use, to change their software to non-approved third-party software of their choice (because a secure bootstrap process will load both a DRM-secure OS and DRM-secure applications) as you claim. They will only be allowed to use locked-down lock-out-enabled publications and software. TCPA is to be totally avoided because in the long-term it will hurt ordinary people using home computers and other TCPA-hardware. The only gainers are the publishing and hardware industries -- not surprisingly they're the ones pushing TCPA.

Re:I'm sorry but totally avoid TCPA

[spitzak]

I have also read those papers. Very carefully. Everything that is in there could be achieved with a chip that lets you read the keys. In fact it would be totally secure even if the remote attacker knew all the keys (thats how PK works).

The fact that you cannot read the key, and thus cannot simulate the TCPA machine on a different piece of hardware or with a software emulator, is only for DRM. I challenge you to come up with a single reason for this that is not equivalent to DRM.

IBM may be the "nice guys" in that they use Linux, and they are trying to make this even "nicer" by using Linux to run this TCPA code. But I fear this is an elaborate scam to try to fool the opponents of this into endorsing it.

Re:I'm sorry but totally avoid TCPA

[Kickasso]

TCPA will be used [...]

This is pure speculation. You don't know. If it will be profitable to use it by locking content, it will be used this way. If more money is waiting to be made with unlocked content, then unlocked content will be produced. I personally don't know anyone who would consider buying unmovable content, but merely uncopyable content is not perceived as a problem by lots of people. So presumably producers of unmovable content will go bely up because nobody will buy their wares.

Re:I'm sorry but totally avoid TCPA

[Anonymous Coward]

They want to do the business with the TCPA keys, selling TCPA keys of sixtyllions (US) of keys .. that it never goes to the end ..

open4free

Re:I'm sorry but totally avoid TCPA

[SiliconEntity]

The fact that you cannot read the key, and thus cannot simulate the TCPA machine on a different piece of hardware or with a software emulator, is only for DRM. I challenge you to come up with a single reason for this that is not equivalent to DRM.

How about an online auction site that only wants to let people use approved clients, to prevent "sniping" and other unfriendly bidding prqactices?

How about an online game site that doesn't want people to use cheating clients which allow them to see through walls, use auto-targetting and other features which are ruining so many online games?

How about a P2P system which wants to make sure people are running legitimate clients that report accurate hashes of the songs available, to prevent the RIAA from salting networks with bogus songs?

None of these are DRM, but they all require that people not be able to simulate or fake TCPA, because then they could run bogus clients which would not follow the rules. There are many good applications for setting up networks where you know that everyone is running "good" software and no one is cheating. This is an important capability provided by TCPA (and Palladium).

Re:I'm sorry but totally avoid TCPA

[russotto]

Sorry, but TCPA pretty much can only be used for evil. The "killer app" for TCPA is DRM. The way TCPA enables -enforceable- DRM have been posted and written-about ad nauseum.

TCPA probably wasn't devised with DRM in mind; it resembles the old "compartmented workstation" idea, and I imagine that's where its roots lie. But DRM is certainly the blazingly obvious use for it, and unlike other DRM schemes, TCPA-based schemes can actually work on general-purpose hardware.

Re:I'm sorry but totally avoid TCPA

[Alsee]

None of these are DRM...
then they could [] not follow the rules.

You just contradicted yourself!

where you know that everyone is running "good" software... an important capability provided by TCPA (and Palladium).

And it fails. The simple fact is that people own their property. You have no right to control what they do with their property, and what's more it is impossible to control what people do with their own property. No matter how secure they make TCPA the fact is that you can dig you encryption key out of the chip in a well equipped college lab. Anyone who does so essentially gets "God level" control over the TCPA system. You have no right to stop them and it is impossible to stop them.

-

Re:I'm sorry but totally avoid TCPA

[Alsee]

Have you looked at what we have done?

Aside from DRM and denying people control over their own computers, I defy you to name a single thing you have done that you couldn't have done just as well with an identical system where people were NOT denied access to their own keys.

-

Re:I'm sorry but totally avoid TCPA

[Anonymous Coward]

shut up Alsee. No one cares what you think about TCPA. Fact is that you are completely off-base, as shown in a previous discussions about TCPA. Just shut your trap and leave. If you really did read all those specs, and you had a real argument, the world would know about it by now. Of all the talk against TCPA, your argument is never mentioned. Odd isn't it? You would think that if you had a real argument, some tech-minded writer would pick up on it in an instant. Of course, if you did read up on the specs, you wouldn't have been able to post your 3500 comments to slashdot. We doubt you actually know what you're talking about.

Re:I'm sorry but totally avoid TCPA

[Anonymous Coward]

shut up Alsee. No one cares what you think about TCPA. Fact is that you are completely off-base, as shown in a previous discussions about TCPA. Just shut your trap and leave. If you really did read all those specs, and you had a real argument, the world would know about it by now. Of all the talk against TCPA, your argument is never mentioned. Odd isn't it? You would think that if you had a real argument, some tech-minded writer would pick up on it in an instant. Of course, if you did read up on the specs, you wouldn't have been able to post your 3500 comments to slashdot. We doubt you actually know what you're talking about.

Re:I'm sorry but totally avoid TCPA

[DarkDigger]

Joe Consumer doesn't know the difference. They'll continue to buy whatever they're told is good for them.

Re:I'm sorry but totally avoid TCPA

[moncyb]

What if people don't realize their content will be unmoveable until they buy a new computer and try to move the files? It's the same thing with Lexmark printers. People buy them and don't realize they'll be charged up the butt on ink cartridges.

It's not as if everyone does hundreds of hours of research on DRM before the buy a computer. They may not even know it is a DRM system at all. They probably won't even know what DRM is. They'll just wonder why certain files won't copy, and either think they don't know how to use their computer or think their computer is screwing up.

The people pushing DRM are deceptive too. They call it "security" or "trusted computing", then tout it as a way to prevent viruses and spam. They don't say end consumers won't be able to back up their hard drive. They don't say end consumers will lose software and other "IP" they legally purchased if they buy a new computer or their system dies. They don't say users may not be able to copy files the users origionally created themselves, because for whatever reason the file got tied up in the DRM system--maybe they checked the wrong box, maybe the developer saved as DRM by default, maybe the developer didn't give an option to save as plaintext. There are a lot of down sides to DRM, and people will find them out the hard way, assuming they figure them out at all.

Re:I'm sorry but totally avoid TCPA

[spitzak]

How about an online auction site that only wants to let people use approved clients, to prevent "sniping" and other unfriendly bidding prqactices?

Download a client that uses encryption, and download a new one every now and then.

How about an online game site that doesn't want people to use cheating clients which allow them to see through walls, use auto-targetting and other features which are ruining so many online games?

Download a client that uses encryption, and download a new one every now and then. If you send model data, send it encrypted and send a decoding key at the very last moment.

How about a P2P system which wants to make sure people are running legitimate clients that report accurate hashes of the songs available, to prevent the RIAA from salting networks with bogus songs?

Doesn't this require some special "won't run if owned by a member of the RIAA" chip? I was not aware that was a feature of TCPA.

Re:I'm sorry but totally avoid TCPA

[SiliconEntity]

How about an online game site that doesn't want people to use cheating clients which allow them to see through walls, use auto-targetting and other features which are ruining so many online games?

Download a client that uses encryption, and download a new one every now and then. If you send model data, send it encrypted and send a decoding key at the very last moment.

How will encryption help? The client has to know the key in order to decrypt the data. And a bogus client can receive and use the key just as easily as a valid client.

Are you relying on "security through obscurity", where you write a convoluted client, don't release source code, and hope it takes people a whlie to figure out where the keys are buried in it? Please! Those systems are easily cracked and totally insecure.

The method I proposed, in contrast, provides strong security which relies on TCPA technology and hardware-based encryption.

How about a P2P system which wants to make sure people are running legitimate clients that report accurate hashes of the songs available, to prevent the RIAA from salting networks with bogus songs?

Doesn't this require some special "won't run if owned by a member of the RIAA" chip? I was not aware that was a feature of TCPA.

No, it requires a client which is written to accurately report the hashes of songs that it has, and then to upload the same versions of those songs and not substitute bogus versions. This prevents RIAA agents from claiming to have good versions of songs (that match the widely-distributed hash) and then providing repetitive junk when people ask for the songs.

With TCPA, remote systems can verify that the client is a good one which behaves in this way and doesn't cheat. Without TCPA there would be no way to know what software the other guy's system is running and no way to be sure that it will behave as desired.

This is why it's called "Trusted Computing", by the way. It gives you reason to trust the behavior of a remote system.

Re:I'm sorry but totally avoid TCPA

[FeatureBug]

I think most truly independent observers who are not TCPA cronies and who have studied TCPA have come to the same conclusion: the one application of TCPA which will proceed with absolute certainty is DRM enforcement.

How much would you be prepared to stake against TCPA being used for DRM enforcement on consumer electronic devices including PCs and home entertainment consoles? You'd be a fool to stake much. The differences between unmoveable content and uncopyable content are unknown to most of the world's population -- heck, most don't even have a electricity!

Re:I'm sorry but totally avoid TCPA

[FeatureBug]

There are other reasons but it's not possible for me to discuss them here.

Re:I'm sorry but totally avoid TCPA

[Kickasso]

Of course it will be used for DRM enforcement. The thing is, there are many ways to enforce DRMs. You can give the user this set of rights or that one. You know, broader or narower. For the time being, DRM shops that give their users more rights, win. There's no indication that the trend will change any time soon.

Re:I'm sorry but totally avoid TCPA

[FeatureBug]

On second reading, I think you've actually slightly misunderstood my overly long 4th sentence above. I don't -- and didn't -- disagree with you that uncopyability of the TCPA keys is vital to DRM. What I meant was that making the TCPA keys copyable would meet some objections to TCPA such as the inability to access legally purchased music and video archives using future hardware/software that is different from the particular TCPA system used at the time of purchase. Open architecture + open keys => software emulation => permanent access to legally purchased music and video archives => karma.

Re:I'm sorry but totally avoid TCPA

[FeatureBug]

"Of course it will be used for DRM enforcement."

Ok, let me get this clear: You're now agreeing with me that it's not "pure speculation" as you said in your previous comment. Shame, I was hoping you'd stake something more than your reputation. You really should have a go at not contradicting yourself every few minutes, or not :-)

What's the DRM like at these "DRM shops" you were talking about? Perhaps you don't know because you don't live in the US or in Europe but the six largest most successful publishers in the US and Europe are all seeking technical ways to protect their publications more stringently than they have ever done before. The trend is definitely to remove fair-use rights from consumers who don't yet understand the implications. Consumers have no choice about which DRM exists in the mass market because given the choice, they'd choose NO DRM!

Re:I'm sorry but totally avoid TCPA

[spitzak]

How will encryption help? The client has to know the key in order to decrypt the data. And a bogus client can receive and use the key just as easily as a valid client.

The key is sent when the data is to be displayed to the user. Before the user can see it it is just blocks of garbage and no cheat program can use that for anything.

Yes, I am relying on security through obscurity. That is why you must allow new clients to be downloaded, so that you can update them faster than they are cracked.

In any case all your suggested uses involve 2-way communication between a client and a server and I think there are other solutions that do not infringe on your ability to do arbitrary things to the client and to the data on the client. The server can be assummed to be secure, that is a huge difference from the DRM situation.

Re:Trustworthy digestion

[Anonymous Coward]

"Data can be protected with a secure pathway from the keyboard through the computer to the monitor screen, preventing it from being secretly intercepted or spied on"

Food can be protected with a secure pathway from the mouth through the bowels to the toilet, preventing it from being secretly intercepted or spied on as well, but that doesn't make eating safe.

And how does this prevent people from looking over your shoulder?

What about an emulator?

[Yartrebo]

Couldn't this be defeated by running a Pentium-with-palladium emulator. It would implment all the normal instructions (like add, jmp, etc) properly, it would handle the authentication instructions by always saying yes, and it would handle encryption and decryption opcods with noops. For the icing on the cake, it could log all keys sent to it to /var/www/html/keys.txt.

You would start with a freshly formatted harddrive (prefferably non-DRM crippled, but as long as it can run Linux and your emulator, it's fine) and install Linux on it. Then you would install your Pentium emulator with fake DRM support (a bit like Wine). Then you would install your Windows-with-DRM through the emulator. All the DRM software wouldn't know the difference.

Assuming that a DRM system will allow unsigned code to run (and just stop you from modifying/copying signed data), this will allow crackers and rippers to make perfectly functional non-DRM programs and media files that will run on normal (DRM-crippled) systems, and if not, then there will be a HUGE incentive to get uncrippled machines, much like mod chips for game consoles.

Re:What about an emulator?

[hanssprudel]

Yes, but you need a root key that is signed by some authority (the kind of keys that are embedded in the chips).

If you can get ahold of one of these keys, then you can simulate running a "trusted" system and cheat the DRM. They won't be easy to get ahold of though. Modchips will probably prove a better avenue.

Re:What about an emulator?

[Minna Kirai]

Couldn't this be defeated by running a Pentium-with-palladium emulator.

An assumption that DRM-proponents sometimes forget to mention is that the system will require government cooperation to work at all.

Specifically, anyone who cracks open DRM hardware to read keys that could be used to make an emulator must be treated as the highest class of terrorist. To protect the American way, corporate property must be respected!

DRM technology is really only there to make the process of circumventing or emulating it so difficult that only a small number of smart, dedicated people can accomplish it. Those people can be suppressed by federal marshals (if US citizens) or FA-18s (if foreigners). The rest of the masses won't be able to defeat the hardware.

Re:What about an emulator?

[SiliconEntity]

An assumption that DRM-proponents sometimes forget to mention is that the system will require government cooperation to work at all. Specifically, anyone who cracks open DRM hardware to read keys that could be used to make an emulator must be treated as the highest class of terrorist. To protect the American way, corporate property must be respected!

Probably the DMCA is enough. Cracking open a Trusted Computing chip will count as circumventing copyright protection technology, which is criminalized by the DMCA. No new laws are needed.

Ironically this suggests that TCPA and Palladium *need* to be construed as being used for DRM, in order to gain the protections of the DMCA. Both sides try to distance themselves from the DRM idea, but if their chips really weren't going to be used for copyright protection, then the DMCA wouldn't apply and it would be legal to circumvent them!

OK

[Anonymous Coward]

As per your request, please bend over and wait for further instructions.

Thank you.

TCPA: the truth

[Anonymous Coward]

So what is TCPA?

A good nifty hardware thing that will include DRM, DCMA, RIAA into the hardware so the software cannot override it. Visit the URL and replace the word "security" with "distribution of illegal material according to RIAA".

Well, no thanks. I don't want. And I wish linux never has it.

How long...

[JamesP]

before the signed version fo Sobig appears?

Out of the frying pan... (will it really work?)

[AYeomans]

For securing most office desktops and servers, NGSCB appears to replace a problem of file and ACL management with a problem of key management. Which you might be able to offload to the vendors at the cost of handing over control (as well as money).

You need to look at how the trust would be *really* managed. In a NGSCB FAQ is the reassuring statement: "One of the most important design goals of NGSCB is to ensure that people are in complete control of the computers they own. That means that the owner has complete control of all of the software that runs on the computer -- in a more visible and powerful way than is possible on any PC today." The problem is in how this actually works.

Yes, you can cryptographically sign executables; and even sign them with the system-unique key, so they can't even run on another system. But how do you practically manage these keys?

It seems that there are several options:

a) "Trust Microsoft/other vendor" - (note the quote above implies this is *not* the model used) - vendor signs *all* valid code. Including all those nice add-on programs that might compete with that vendor. I'm sure I really do not want to hand over that much control.

b) "Trust the user" - user gets to sign all code on their PC. But then the same tools can be used by trojan software to get themselves installed by deceit. So it's not really more secure than sticking "execute" permission bits on valid programs.

c) "Trust IT department (for businesses)" - has more potential, but at the local resource cost of trying to establish whether trusted code is trustworthy - on thousands of systems.

Each has its problems, and none of these are a good defense against classic buffer overflow attacks - or simply exploiting poorly-designed but signed code? And what precautions are needed against key loss? Long-term access to vital corporate data protected by DRM scares me.

Is there a simpler way?

Many of the purported benefits could be achieved by much simpler mechanisms:

a) Using execute (x) permission bits correctly, and lock down ACLs. If all code loaded onto a system always had execute bit cleared, and there was a separate process to explicitly grant permisson (chmod), this would defend aginst most rogue code. Installation would be more tedious (as it has to be in NGSCB-protection), though some simple code-signing could be used to automate that. But administrating fine-grained security will probably be costly, whatever technologies are used.

b) Use write-protected filing systems. I'm old enough to remember when hard disks had write-protect switches. They worked very well! Software-enforced write protection, as in some BSD systems, is the next best thing. Run-from-CD systems such as Knoppix have similar benefits. Of course, you need an operating system designed to segregate read-only data from read-write data. Not so easy with Windows registry.

c) technologies such as exec-shield (http://www.kerneltrap.org/node.php?id=644) and the OpenBSD stack and execution protection (http://www.openbsd.org/33.html) have great short-term potential.

Other uses for NGCSB

It's not all negative, I can see some benefits of having secure storage on PCs.

Being able to store unique device keys (e.g. ssh server keys) would be nice. You can do this today with smartcards or USB tokens, apart from the small issue that neither are fitted to systems by default.

Being able to store cached credentials and passwords in a secure area that even administrators cannot read would improve confidence that users could not be impersonated. This needs very careful design, of course, on which items of software can be trusted to read the secure data.

And for dedicated appliances such as firewalls, having a trusted boot sequence would give more confidence that the system software could not be corrupted.

Prove integrity?

[julesh]

...able to check that none of its software is compromised and even (in a future version) prove its integrity to a remote system.

How do you do that? I mean, how do you prove that the system is secure and not just pretending to be secure by doing *almost* all of the things that would be needed to be secure?

I could understand how a system could (eg) verify a signature on a kernel in order to boot it up, but this is a Linux system, therefore:

1. Its open source. You must (by requirements of the GPL) be given everything you need to compile a derivitive work of this. If the kernel is signed, that means the keys must be supplied with the source code, otherwise part of the build environment which isn't normally shipped with the compiler or major components of the operating system isn't included.

2. Has the kernel module loading facility been disabled? If it has, its crippled and worthless. If it hasn't, then you can load a module that pretends to be part of the kernel, accesses the DRM hardware and pretends to the outside world to be a secure environment when, in fact, it isn't.

Re:Prove integrity?

[Minna Kirai]

2. Has the kernel module loading facility been disabled?

No, but it verifies that any modules have also been signed before loading them. (Alternatively, the superuser could force an untrusted module to be loaded, but this will taint the whole kernel and it will lose the ability to open protected files until you reboot)

1. Its open source. You must (by requirements of the GPL) be given everything you need to compile a derivitive work of this.

The currently prevaling legal interpretation (shared by Linus Torvalds amoung others) is that the signing key cannot be construed as part of the source code. Source code is human-readable description of what software does. A key is just 1024 bits of random noise.

The argument is that the GPL requires people to give you the source code to a program; they don't have to buy you the hardware needed to run it.

Suppose you buy a Playstation5 from Sony and request the kernel code under GPL. If you compile the kernel without having the key, you've got a working kernel. The hardware you own won't load it, but that's not Sony's problem. If you sign a pile of NDAs and supply a check for $65000, Sony will rent you one of the same developer-class machines their own programmers use to write games. That system will load unsigned code, although you've sworn in blood not to abuse that great priviledge.

I would rather that this legal interpretation doesn't hold, as it perverts the intent of GNU "Free Software", but it hasn't been seriously challenged yet.

Re:Prove integrity?

[SiliconEntity]

Suppose you buy a Playstation5 from Sony and request the kernel code under GPL. If you compile the kernel without having the key, you've got a working kernel. The hardware you own won't load it, but that's not Sony's problem....

I would rather that this legal interpretation doesn't hold, as it perverts the intent of GNU "Free Software", but it hasn't been seriously challenged yet.

It makes a lot of sense to me. Otherwise, under your preferred interpration, I could sign your GNU software, and set up a machine that will only run the signed version. Then when someone creates a derivative work, it would not run on my machine. You wouldn't be able to redistibute it without my key. So I could hold you hostage and prevent your redistribution, by your interpretation.

Just because someone chooses not to run or trust modified versions of software, that does not stop people from making changes. Even if that "someone" is important, like a successful PC manufacturer, or a widely-used online service, it doesn't change the principle.

GPL lets people modify code for their own use; it doesn't give anyone else an affirmative duty to respect or utilize the modified code in the same way as the original. But that's basically what you're asking for.

Re:Prove integrity?

[Minna Kirai]

I could sign your GNU software, and set up a machine that will only run the signed version.

The argument I would hope to make (possibly needing a modified GPL license version to explicitly require this) is that by signing the software (which is my copyright), you have created a derivative work, which is illegal. The only way I'll permit you to distribute it is if you agree to supply the recipients with anything needed to create the binary they got. This means the source code, the compilers (if they're hard to get), and the private key.

Of course, if you're obliged to give out that private key, then there was no reason to sign at all.

As a non-lawyer, I can't construct a good license to enforce that requirement, but in time the FSF will be forced to address this issue. They might even be able to content that the existing GPL already suffices.

Then when someone creates a derivative work, it would not run on my machine.

You keep using things like "my machine" and "someone chooses", which are misleading. In the common case, the machine has been sold long ago, and the current owner might actually prefer to choose the derivative software. The user-hostile DRM hardware has denied him that choice.

(The hardware vendors, of course, will argue the user made his choice when he bought the machine. Even accepting that position, one can't claim that such behavior supports choice, flexibility, or consumer power. Koenig made an aprops quote while appearing in "Batman: Dead End")

PS. Note that similar hard-DRM systems might also be implemented without signing, by storing hashes of an approved-kernel whitelist on a ROM in the hardware. This has practical disadvantages- it's harder for the vendor to ship a new kernel revision when bugfixes happen, and it might be easier to build modchips. But it could offer the vendor a legal protection from the license I describe, since he was not distributing a derivative work of my software without the full materials needed to recreate it.

PPS. I will further note that individuals have already attempted to exempt a single magic number (rather like a key) from the GPL requirement to provide source code. It failed. I don't remember the defendant, but you can find the case by searching for the plaintiff, John Carmack. (Yes, I know settlements are weak precedent!)

Re:Prove integrity?

[SiliconEntity]

The argument I would hope to make (possibly needing a modified GPL license version to explicitly require this) is that by signing the software (which is my copyright), you have created a derivative work, which is illegal.

Wow, that's amazing. I can't sign your code without giving away my key. It's astonishing that you think you hold that much power over me.

How would you feel if I simply said "I trust software version N, the one with hash X." Is that okay, or is my comment a derivative work, too? Would you claim that every comment about your software is a derivative work and you get control over how those comments are disseminated?

How about if I make that comment as part of a signed message? Now is it a derivative work? The fact that my statement can be authenticated by a public key?

Because that's really what a signature is, you know - a statement, whose source is verifiable and can be traced to a particular key, or key holder. In claiming the right to control what signatures people make on your software, you are claiming the right to control the kinds of statements they make about your software.

Hopefully it is clear that this approach is a non-starter. The creator of a software program has no such right or power to limit what people say about it, even if those statements are backed up by public key signatures.

Linus Torvalds takes a strong and principled position on the matter in this slashdot discussion. He agrees that the code creator has no control over what signatures people put on it, or what usage decisions are made by those who choose to trust such signatures.

Re:Prove integrity?

[Minna Kirai]

How would you feel if I simply said "I trust software version N, the one with hash X." Is that okay, or is my comment a derivative work, too?

As I explicitly stated in a postscript, asserting that code matching a hash value is trusted is not a derivative work. (The hash contains a negligibly small fraction of the copyrighted work, making it a fair-use exception)

Signing creates a new file with your stuff at the beginning and end and my code in the middle. That means it's a derivative work. (The signed binary contains 100% of the copyrighted work, which is illegal to redistribute without permission)

Hardware vendors can work around that interpretation by distributing hashes and executables separately. That dodge may or may not be a legal loophole.

Re:Prove integrity?

[julesh]

The currently prevaling legal interpretation (shared by Linus Torvalds amoung others) is that the signing key cannot be construed as part of the source code. Source code is human-readable description of what software does. A key is just 1024 bits of random noise.


An interesting interpretation. I'm not certain that it is correct, though. The GPL states:

For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

I would certainly contest that the signing key is part of the 'scripts used to control compilation and installation', as it is impossible to compile and install the kernel without it. Neither is it distributed with any of 'the major components [...] of the operating system'

Ironic? naaah

[instanto]

Anyone else notice the irony of having a Microsoft sponsored advertisement under a article detailing linux & TCPA.

I did before I wrote this, but it was'nt that fun anyway. I think.

TCPA does have good uses

[Old time hacker]

The TPM is a hardware component that implements the security model. It so happens that this exists on a bunch of modern IBM laptops. It is disabled by default.

Background: The TPM contains a number of PCRs. These are (roughly) hashes of bits of code -- the BIOS, the bootloader, the kernel, etc. The TPM also contains a private/public key pair which is generated when you reinitialize the TPM (i.e. the private key is not known to anybody).

The TPM can be used to encrypt a blob of data using the private key. It can also mark the encrypted blob such that it will only decrypt it if (some set of) the PCRs have the *same* value.

What is this good for?

This means that you can tell if your kernel has been modified in a very secure way. If your application is stored encrypted on disk, then you can ask the TPM to decrypt it (probably you just ask it for the key). It will only perform this operation *if* the boot process was the same as when the application was setup.

It means that someone with a boot floppy cannot get to your data (different boot process). You could also arrange to have the data protected from single-user mode.

However, there is a downside -- upgrading the OS becomes really tricky!

MOD PARENT UP +6 INSIGHTFUL!!!

[Anonymous Coward]

You're very right. Encryption is *not* the same as DRM/PALLADIUM, or even TCPA. If I send you an encrypted email, the fact that it's encrypted doesn't prevent you from printing it out or forwarding it to someone once you've decrypted it. Computers should obey their users, not vice-versa.

Blatant zealot propaganda.

[Kickasso]

You cannot copy the keys inside TCPA hardware. True.

Every time you buy a new PC with TCPA you will not be able to copy the old TCPA keys on your old PC to your new PC. True.

This means you will completely lose access to your videos and your music which you legally purchased and used on your old PC. Not necessarily true, because TCPA hardware doesn't directly contain keys to these items. It only contalins keys to your OS. Your OS contains keys to your DRM-enabled apps. Your apps have the keys to your multimedia.

If your apps are able to move keys from one computer to another, there's no problem. If they are not, do not use these applications. Moving (not copying) keys from place to place is a basic function that should be supported by every DRM-enabled app.

Tinfoil for the mad hatter

[poptones]

If you have a collection of AVI movies and MP3 songs, where did you get those? Is there some great archive sites I've never heard of where movie and music studios are giving away tens of thousands of high quality downloads? Is McGraw-Hill offering all their new books in PDF downloads? See, I keep hearing "content provider this" and "content provider that" but I still don't see any evidence this new scnario represents any sort of change from the one we have already...

Are there any websites that offer high quality streaming video? Or even high quality downloadable movies? How about high quality MP3s? Anything at all the publishers are offering "legally" in a format of higher quality than I have been getting (for years) absolutely free via USENET?

How about plain ol' "information" websites? Hmmm... let's see. Geocities might be a good example. No streaming video (big deal) but they host tens of thousands of home pages. So does AOL. So let's say they decided to use this Palladium-Longhorny stuff to keep their "members pages" available only to those willing to use their client software.

Uhhhh... so what? I can't recall the last time I visited a geocities page (much less an AOL members page), and I'm pretty sure if I go over the proxy logs I'll not find anything more than a few "404" pages with their name on'em. Yahoo? I used to read a couple of their groups, but they're gonna send spam to you one way or another so I quit that long ago. There's just as much content in usenet, and I get to call the shots.

See? This doomsday scenario really isn't much different than what we have now - it's just more of the same but with encryption. I really don't give a shit if universal wants to put their movies online and lock them away behind MS-centric operating systems, because I wouldn't use the service even if they slapped a Penguin on the door and made the "movie viewer" part of the RH12 base distribution. I wouldn't use it because a) I don't have broadband and b) if I want my own copy of a movie I will rent the DVD and rip it myself, or do a sneakernet trade for a copy from someone I trust to do a good job of it.

"Content providers" will lock away only as much as is economically viable. If there's no money in it, they won't lock any of it away. But right now they have it all "locked" away (at least as much as they are able). So what does any of this "evil" new technology change?

Having a system I can trust even if it's hanging out on a raw IP is a very good thing. If the tradeoff I have to accept is that Universal will use the same technology to sell movies to people with plenty of disposable income, more power to'em.

Re:Tinfoil for the mad hatter

[Minna Kirai]

But right now they have it all "locked" away

No they don't. Look at the page you're reading now... megabytes and megabytes of "content". Visit msn.com or nytimes.com or even mapquest.com. What do you find there? More and more content.

Now, you are correct that the entertainment industry (RIAA + MPAA) doesn't allow a significant amount of their product to be released in digital format, and that hardware-enforced DRM would encourage them to release more. But music and videos aren't the entierty of "content"- in fact, they're arguably the least useful content, from the standpoint of doing practical work.

The proliferation of DRM technology would also lead existing websites to use it. Many of the free newspapers would go away. The minority of sites that remain free will probably use DRM to mandate user login accounts. The even smaller minority that don't log r users will probably engage some DRM flags to stop their files from being printed or locally stored.

That kind of behavior will make a computer running Open Source software useless for general-purpose web-browsing. (And web-browsing is the #1 most important task most computers are used for)

PS. Some people will object and say "A DRM computer can use an Open Source OS! As long as a 3rd party signs the specific binary that's running, the end-user can be allowed to read the source code". That may be true, but if the user has no ability to modify the code he runs then it's not Free or Open software from any practical perspective.

Re:Tinfoil for the mad hatter

[poptones]

The proliferation of DRM technology would also lead existing websites to use it. Many of the free newspapers would go away. The minority of sites that remain free will probably use DRM to mandate user login accounts. The even smaller minority that don't log r users will probably engage some DRM flags to stop their files from being printed or locally stored.

Visited the NYT lately? How about LA Times? How about MIT Press? There are already hundreds, if not thousands of sites, locking their content away behind logins - they don't need DRM to do it.

So what? More handwaiving and doom and gloom. The fact is there's plenty of free sites now, and there will be then. What is of value to society activists will continue to make available no matter the policies, and what is not of substantial value (like most of those sites already barricaded behind "free accounts") will either barricade themselves in further, or not - it won't matter either way, because people will alwayas find foils IF it is worth the effort. And if it isn't, they don't matter anyway.

Fantastic example: Traci Lords. You can't buy most of her films in the US - in fact, you can be arrested for even having some of them. How long would it take you to find a place to order them on the internet? Or to find them in the newsgroups, or on p2p? Arguably not much societal value there at all, and yet no US laws can prevent anyone who wants the content from acquiring it.

It's a big world out there. When free expression is no longer possible on US soil, US dollars will make sure there's a world of domains out there where speech remains free - even english language speech. And you don't need to look far to see it's happening already...

Re:Tinfoil for the mad hatter

[Minna Kirai]

Visited the NYT lately? How about LA Times? How about MIT Press? There are already hundreds, if not thousands of sites, locking their content away behind logins - they don't need DRM to do it.

You're avoiding the point. They already use logins today, and will in the future. But someday they can have these logins protected by DRM technology. They will get a minor economic advantage from this extra protection, but newspaper margins are slim, so they'll grab for it.

Then, it will be impossible to visit those sites with an untrusted OS. It will be impossible to build a PC, compile Linux, compile Mozilla, and use that to browse the web. The freedom of disorganized amateurs to create useful computer systems will be gone.

When free expression is no longer possible on US soil, US dollars will make sure there's a world of domains out there where speech remains free

That's a head-in-the-sand argument. "The government cannot now enforce a prohibition against a behavior. Therefore they will never be able to prohibit it."

Sorry, but in the face of ever-increasing computer power, that viewpoint just doesn't hold up. If you don't believe me, Lessig has published extensive documents describing exactly why.

Re:Tinfoil for the mad hatter

[Anonymous Coward]

Which of Traci Lords' films can get you arrested? What happens in them?

Re:Tinfoil for the mad hatter

[illtud]

Are there any websites that offer high quality streaming video? Or even high quality downloadable movies?

I'm a bit late reading this, but for information:

http://www.archive.org/movies/prelinger.php

The Prelinger film archive online is fantastic. Yup, it isn't Blockbusters, but there's great stuff there available under a really generous licence. A great resource for VJs and samplers.

Re:Tinfoil for the mad hatter

[yerricde]

Are there any websites that offer ... high quality MP3s?

You mean other than eMusic, now that it has upgraded its MP3 encodings from 128 CBR to 192 nominal VBR?

Anything at all the publishers are offering "legally" in a format of higher quality than I have been getting (for years) absolutely free via USENET?

Server operating systems are available as free software, and they're typically less susceptible to the most common sploits than the Microsoft Windows Server OS that you may be able to find on Usenet.

Suuuure.

[Kickasso]

They have zero bugs, right?

Screw this!

[pair-a-noyd]

So what now?? You have M$ approved Linux??
Under no circumstances will I have anything to do with this Orwellian crap that they are forcing on us.

It's like jumping in a cold lake, at first you're shocked, but after being in it a little while you say, "See, it's not so bad after you get used to it..."

All of this TCPA and DRM and Palladium crap is not about security, it's about KONTROL.
You won't be able to do ANYTHING without permission from someone else.
You'll have to ask for permission to use your computer..

THEY KONTROL YOU

Re:Screw this!

[La Temperanza]

I don't use KDE. Can I have gcontrol2 forced on me instead?

There's a lot of talk

[Kickasso]

about how TCPA will kill open source. This outcome is very probable. But they can also work fine together. There is a solution, and open source people would do good by pursuing it instead of blindly fighting the inevitable.

TCPA needs an agreed-upon, standard microkernel around which different OSes could be built. A whole bunch of new open source OSes and, yes, new Microsoft OSes. This microkernel would be developed by an independent body and signed by DRM-loving vendors. Because it would be very small, and change very rarely, there should be little problem with it. Yes, end-users won't be able to modify it; that's the price one pays. They won't want to do it very much because the microkernel provides very little functionality.

Hardware vendors would release drivers for their wares that would work with this microkernel. These drivers would be otherwise OS-independent and would include decryptors and decoders needed for playing content. The vendors would get their drivers signed, too. (And open-source OSes will get closed-source drivers for free: a nice bonus!)

The rest of the OS and the entire universe of user apps would need not be trusted at all. They would run in user space and be totally unprivileged.

So I think open-source people should approach TCPA and offer to work together along these lines. There's nothing to lose, and much to gain, so why not at least try it?

Re:There's a lot of talk

[Anonymous Coward]

Nope, won't work.
You also have to control the videocard and soundcard. This means that these drivers also have to be signed.
A microkernel is _not_ enough.

Re:The owner of the PC does NOT own the master key

[omen]

The long term problem with IBM's model of the TCPA is exactly the same with that of clipper chip encryption, the owner of the PC does NOT control the attestation master keys.

[ Disclaimer, I'm one of the primary developers. ]

That is blatantly not true. Whoever does the "Take Ownership" command of the TPM controls the master key. In the case of the Enforcer, the admin is the one that owns the TPM.

Omen

Re:Sweet

[omen]

This is innovation.

[ Disclaimer, I'm one of the primary developers. ]

Thanks, we think so too. ;-)

Omen

And this is desireable, how?

[HiThere]

This calls into question the wording of the GPL. Perhaps it needs to explicitly forbid using GPL software to create certain kinds of restrictions.

Monopolies are inherrently evil. This is a step towards creating a new kind of monopoly, and thus should be disabled before it starts.

One needs to question the ethics of anyone who would work on such a project. And one definitely needs to be dubious of any company that would sponsor it. And any purportedly educational system that would foster such research. That something can be done is not sufficient reason to do it. This thing is so wide open to abuse by already powerful and abusive groups that no decent person would have anything to do with it. Except, perhaps, to sabotage it.

All legitimate proposals that I have heard for uses that it could properly serve can be dealt with by other means which are less open to abuse.

Re:And this is desireable, how?

[Minna Kirai]

One needs to question the ethics of anyone who would work on such a project.

That's a fair question. But these Dartmouth guys pass it. They're trying something that we all knew (or feared) would be possible, and demonstrating how practical it really is.

And they're publishing the results, so the public can discuss the implications now, before the Great Irreversable DRM Rollout happens.

It's surely better than if Microsoft, Sun, or Sony were conducting this research secretly! (Oh wait, they probably already have...)

I do not, however, like the attitude of the submitter's blurb, which spins this system as a useful feature to compete with Microsoft(tm), rather than a way to cut off the stream of cheap, general-purpose computers that make Open Source possible.

Re:And this is desireable, how?

[SiliconEntity]

I do not, however, like the attitude of the submitter's blurb, which spins this system as a useful feature to compete with Microsoft(tm), rather than a way to cut off the stream of cheap, general-purpose computers that make Open Source possible.

As the submitter, I will just comment that my ideal world is one of diversity and competition. I would love to see some content sold with strict DRM limitations competing against other content sold without restrictions. I would love to see closed systems competing against open ones. I would love to see open source competing against proprietary software.

I want people to have choices and alternatives. Technologies like Trusted Computing offer new possibilities for how people can use their computers. Now that most of the lies and falsehoods have been eliminated (Your system won't boot linux! Only microsoft signed code will run!), people are beginning to understand the tradeoffs which will exist if they choose to purchase and enable this technology.

For every company that chooses to impose harsh restrictions on the usage of its software and data, there will be another (or an open source project) which distinguishes itself by openness. People will still have alternatives and choices, even more than they do today, because today it is impossible to create a truly closed and trusted network-wide application.

This technology has good uses and bad, but I trust individuals, acting together in the marketplace, to teach the vendors which usages are acceptable and which are not. No company, not even Microsoft, has a monopoly so strong that they can simply lay down rules without care or concern about the impact on their customers. Every company is subject to the discipline of the market, and the same is true for open source projects as well.

If a project or company succeeds, ultimately it is by meeting the needs of its customers and users. And in order to best meet those needs, the widest possible range of technologies must be made available. That is ultimately why I support Trusted Computing, because it is a technology which provides new alternatives for how software communicates and manages its data.

Re:And this is desireable, how?

[Minna Kirai]

Now that most of the lies and falsehoods have been eliminated (Your system won't boot linux!

It won't. Will Linus Torvalds be able to pull a tarball from kernel.org, compile it, and boot it on the system?

No he will not.

That ain't Linux.

Not in any useful way. It's been gutted, it's soulless, it's dead.

Re:And this is desireable, how?

[SiliconEntity]

Now that most of the lies and falsehoods have been eliminated (Your system won't boot linux!

It won't. Will Linus Torvalds be able to pull a tarball from kernel.org [kernel.org], compile it, and boot it on the system?

No he will not.

Yes, he will.

His system will still boot, but it may have a different "fingerprint" (crypto hash) than a widely-accepted Linux+TCPA system. This could prevent it from participating in TCPA-dependent network applications. It might not be able to download DRM-protected data, for example; or participate in an online game which required users to use a TCPA-validated OS.

Is this system "gutted"? I wouldn't say so. He could still do a lot of things with the computer. It just wouldn't be able to participate as fully in those parts of the net that require TCPA.

And keep in mind that Linus Torvalds himself endorses this technology! I quote, "I want to make it clear that DRM is perfectly ok with Linux!"

Re:And this is desireable, how?

[Anonymous Coward]

This calls into question the wording of the GPL. Perhaps it needs to explicitly forbid using GPL software to create certain kinds of restrictions.

Pish. The GPL is just bytes in a file, easily ignored. Even if you could find a violator of this clause, you'd still have to come up with evidence and spend years in court to try and redress it.

Now, if you could somehow write your application so that it would only work if it *knew* that the user was in compliance with the GPL, that would be cool. You could have your copyright and usage restrictions enforce themselves.

But you can't just check the OS, or make a function call. That's too easy to fool.

I know! If you have some cryptographically secure ID in hardware, you could register the OS as GPL+antiMonopoly compliant. Then your app would know that it could safely run. And it could require that copies of the source exist along with the binary, like the GPL says.

Now, if only we could get the hardware manufacturers together to implement a chip like this on the motherboards, we'd be set. Then, you could just make a compliant version of Linux, and go to town.

Attestation monopoly:change the key=MS DRM not run

[NZheretic]

Note that I said "the attestation master keys ". Changing the key via TPM would still require content providers to accept the new attestation key.

This leads to the same escrow agent model which is far to open to exploitation by The New American Corporate Soviet.

The latter link explains

Attestation Monopoly

Microsoft's NGSCB model for DRM content management grants Microsoft effective root digital certificate control over both software and content. It would be a monopoly even stronger than Microsoft's existing desktop dominance. Just as with Microsoft's proprietary file formats and protocols, the network effect would result in any non-dominate player or vendor facing too great a barrier to provide effective monopoly negating free-market competition.

Binaries die, Source code lives forever

[ewn]

The old sentence gets even more valid with TCPM. We all are used to the fact that binaries are tied to the computers we're using. Buy a new computer to replace your crashed old one, find out you have to use a newer version of the kernel to support Bozo Gadget 2.78, reinstall your binary application from backup, find out that your new system has glibc 3.14 where the old binaries were linked against libc 1.41, yell an expletive, dig for the source, recompile. Been there, done that.

With TCPM, this will only be stricter, not fundamentally different. Use the Source and you'll be fine.

Confusing

[Krunch]

Wasn't TCPA evil last month ? GPL'ed software that use TCPA. Where is the world going to ?

Fair use law

[Nucleon500]

What we need to avoid all of this is strong digital consumer legislation that requires that every digital rights management system include escape hatches to allow for Fair Use, format shifting, platform shifting and copyright expiration. That would prevent the abuse of the technology without taking away the usefulness of TCPA.

It's a sad, but yes, legislation to protect fair use is very necessary. Previously, fair use was a defense against a copyright infringement suit, and nobody worried about it being taken away because it wasn't technically possible. Now, we see that it is technically possible to mostly (but not completely) to make fair use impossible.

That's not bad in itself, except that with legislation like the DMCA, although fair use may always be technically possible, can now be made legally impossible. For example, format shifting DVDs, which would be fair use, is now probably illegal.

Normally, even the ability to destroy fair use on a technological and legal level isn't enough, because it won't sell. The rights of fair use are worth quite a lot to consumers, and they would pay for them. Unfortunately, there's no real competition in any content industry, so if the entire industry decides to mandate technically and legally protected DRM, it is forced on the consumers, who have no other choice.

The unfortunate combination of advances in cryptography, reactive legislation, and poor market dynamics are putting fair use rights in jeopardy. There ought to be a law!

Re:The owner of the PC does NOT own the master key

[Alsee]

Whoever does the "Take Ownership" command of the TPM controls the master key.

False. The TCPA design specification explicitly requires that the owner MUST NEVER be permitted access to the TPM master key. The entire purpose of TCPA is to keep this key secure against the owner.

If the Take_Ownership command gave you access to this key then there would be nothing wrong with TCPA.

-

A few points

[riptalon]

Your analog hole arguement is flawed because in the future there will be no analog devices. They exist now but soon they will stop making them and the existing ones will all break in time. The whole point of DRM is that it has to be pervasive. You will not be able to record a video off your computer screen using a digital video camera because the camera will have DRM in it as well. Everything will. There will be a black rectangle where your screen is on the video because the camera will recognise that it is "protected content" from the watermark and will not record that section of the image. All computers and monitors will be DRM enabled so there will be no way of stripping the watermark out before you display it.

TPCA/Palladium is being developed because it is useful for DRM. It may have other uses but they could be achieved in other ways. All security problems (defined as users/programs doing things that the computer owner doesn't want done) can be handled at the firmware/OS level (with the possible addition of a lock on the case so a user can't pull the battery on the CMOS). Putting this functionality in hardware is only necessary if the owner of the computer themselves is not trusted (i.e. a DRM setting).

Why if all this security stuff is such a pressing problem does Windows not allow for only running signed binaries already? Or Linux for that matter? 99 percent of this can be implemented at the OS level already. And the rest could be achieve by flashing a new secure bios. The reason it has not been done is a) there is no real problem that merits it and b) if it was done it would compete with a hardware solution, which is necessary for DRM.

You didn't read too carefully.

[Kickasso]

I wrote about that. Luckily, each card vendor can write driver(s) for their range of cards and get them signed. These drivers would work in any OS that uses the microkernel.

Dude, Lessig is simply wrong...

[poptones]

Duh. Where do you get this...

hen, it will be impossible to visit those sites with an untrusted OS. It will be impossible to build a PC, compile Linux, compile Mozilla, and use that to browse the web. The freedom of disorganized amateurs to create useful computer systems will be gone.

From Hollywood charging for content? Jessus fucking christ, get out of that chair and go outside. Or even try typing "www.google.ru" instead of just "google." There's a whole fucking world out there, and Hollywood doesn't conmtrol it. The US government doesn't even control it.

And the more pressure there is for this sort of thing, the greater will be the effort made to destabilize it, both from within and without.

Sorry, but the US doesn't own the internet. And the US doesn't make all the computers in the world - in fact, most of them come from parts made in China, a country that would love to see US dominance further destabilised.

Re:Dude, Lessig is simply wrong...

[Minna Kirai]

Dude, Lessig is simply wrong...

I'd pay good money to watch you try to withstand him in any legal argument. Scalia can barely stop the guy; you'd be mincemeat.

The US government doesn't even control it.

Have you been paying attention? The US thinks it can control everything, and unless something amazing happens at the next national election, they're going to try.

Sorry, but the US doesn't own the internet.

They own (or can dispatch SWAT teams to) every router that connects the US to the outside world. Might they someday decide to build the PATRIOT firewall which squelches untrusted packets to protect us from the dangers of worms, viruses, file-sharing, and terrorists? They'll jump to work on it the first time an Al-Quaida sympathsizer is caught with a homebrew Sarin recipe on his laptop.

in fact, most of them come from parts made in China, a country that would love to see US dominance further destabilised.

In China, a country that would love for the police to be able to monitor the computer usage of every citizen!

When you start to hold up China as a bulwark against authoritarianism, that should be a warning that things are going very wrong. China wants to sell PCs to the US. They also want to control the communication of their own citizens. By building "user-hostile" DRM, they can advance both goals.

Re:Dude, Lessig is simply wrong...

[poptones]

Uhhh... yeah and stuff. So basically you have NO LOGICAL BASIS for your statements so the best you can come up with is "my dad can beat up your dad?"

Hilarious.

And no one is holding up China as a "bulwark against authoritarianism." That is your misreading, not my statement. China is an incredibly paranoid nation that is going so far as to develop its own national linux based OS because they are so certain the Bill Gates is working in cahoots with the CIA (and they may well be right). This means any "authoritarian" stuff they stick in their OS is almost guaranteed not to work with "authoritarian" stuff here - that's their entire reason for doing it in the first place. But do you really believe they won't design their stuff to be able to "crack" our stuff? Do you really think they will hesitate to provide services "in the name of freedom" simply to bolster their own rhetorical propoganda opportunities?

And China is only one example. In addition to logic, you've completely avoided the whole of eastern euroupe, and most of western euroupe as well. Here is just one example. Eva is a film star in euro who has been appearing nude since she was, like, ten (her mother is a photographer - you might think of her as the twisted, drunken French Sally Mann). Much of Eva's work was done in France (a country where another well known director is still living because he would be arrested in the US) and very little of her work (no matter the age) is even available in the US (despite the fact she was on the cover of "Photo" magazine AND featured in Playboy by the time she was fifteen). Click on the english side (if you dare! Ha!) then click on the russian side and compare - one server, one site, two languages and they really couldn't be more different and still be recognizable as one site. All those "copyrighted" works that you cannot get on the english language pages suddenly appear on the russian pages! It's magic!

You think they're going to firewall in the US? Again, so fucking what if they do? Isolationism is the road this country has been travelling for years now and it's not just because of the internet. Whoopeee. That just hastens the fall of the US as a superpower in the world, which might be good for bringing back those "well paying" factory jobs but is going to royally fuck America's chances to foister such foolhardy technology off onto the rest of the world.

No matter what happens, it balances - all you gotta do is be willing to vote with your feet. This "prison" you're imagining is constructed purely of you own egocentric nationalism.

No one tell Lessig...

Re:The owner of the PC does NOT own the master key

[Anonymous Coward]

shut up Alsee. No one cares what you think about TCPA. Fact is that you are completely off-base, as shown in a previous discussions about TCPA. Just shut your trap and leave. If you really did read all those specs, and you had a real argument, the world would know about it by now. Of all the talk against TCPA, your argument is never mentioned. Odd isn't it? You would think that if you had a real argument, some tech-minded writer would pick up on it in an instant. Of course, if you did read up on the specs, you wouldn't have been able to post your 3500 comments to slashdot. We doubt you actually know what you're talking about.

I don't believe people are that stupid.

[Kickasso]

And I don't believe that corporations believe that people are that stupid.

Look at current implementations of DRM, e.g. iTunes. They do not show any sign of being as draconian as you describe. Why? Because otherwise people wouldn't use them, that's why.

Re:I don't believe people are that stupid.

[yerricde]

Look at current implementations of DRM, e.g. iTunes. They do not show any sign of being as draconian as you describe.

Look at iTunes's competitors. Their policies are, in general, more draconian than iTunes'. And no, we can't count on the continuing availability of iTunes because the Beatles can shut down iTunes and all your iTunes downloads.

Lok at iTunes.

[Kickasso]

You are saying that DRM will be enforced in most stringent way possible, i.e. no moving files between computers etc. This is speculation.

Perhaps you don't know, but there's a DRM shop operating in the US. It's called iTunes. Maybe you should look at how it works. It's nothing like you describe. Perhaps you should ask yourself why.

TCPA

[inertia187]

As businesses stake their very existence on the Internet, PCs, PDAs, and other key computing platforms, the trustworthiness of these platforms has become a vital concern.

Why is that? Should I just take their word for it? Is my car being trusted by the interstate when I take it for a spin? Why must we add this layer?

More Information

Re:The owner of the PC does NOT own the master key

[yerricde]

If TCPA designers didn't have digital restrictions management firmly in mind, then please explain non-migrable storage.

What happens when iTunes dies?

[yerricde]

but there's a DRM shop operating in the US. It's called iTunes.

When[1] iTunes Music Store stops operating, do downloaded phonorecords[2] remain playable?

[1] I say "when" not "if" because the Beatles' record label has the power to go to court and make this a "when".

[2] "phonorecords" are to sound recordings as "copies" are to every other kind of copyrighted work.

License and registration please

[yerricde]

(the following applies to the United States of America)

Is my car being trusted by the interstate when I take it for a spin?

Yes. There should be a rectangular placard on the back of your car, called a "license plate." This is issued by the state governments that fund highway construction.

Re:License and registration please

[Anonymous Coward]

A car can still get onto the onramp without it. There's no physical barrier designed into the system to prevent it.

Personally, I avoid car analogies on Slashdot...

Answer.

[Kickasso]

AFAICT, yes. If in doubt, burn all of them to CDs, because you can.

I know.

[Kickasso]

No, the Beatles can't shut down iTunes downloads already made. Can they sut down an iPod? I think not.