Slashdot Mirror
IBM Trials TCPA Chip Under Linux
keihin writes "From IBM: IBM's Global Security Analysis Lab (GSAL) has done extensive analysis of the Trusted Computing Platform Alliance (TCPA) chip available on some IBM systems. We have the chip running under Linux, and have studied it extensively. In order to clarify a lot of misunderstanding about the chip, we are making available some helpful white papers and open source device drivers for Linux, so that interested people can test and use the chip in an open environment."
I had previously thought that only Intel was involved in the TCP Alliance, but it's good to see that IBM is on-board as well.
Check out *nix.org , a dynamic, informative, and fun portal for fans of BSD, Linux, OS X, & Solaris!
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
Apparently, the TCPA folks keep the list of companies involved private which is why I had never really heard of anyone aside from IBM involved in this alliance.
However, there's a full list here.
Check out *nix.org , a dynamic, informative, and fun portal for fans of BSD, Linux, OS X, & Solaris!
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
Real World TCPA != DRM
Microsoft's TCPA == DRM
Before people get too confused and start to complain (quite reasonably) about the RIAA, MPAA, etc: this chip is not designed to facilitate DRM. In their "why TCPA" article, they explain why it's not even particularly well suited for such systems.
Rather, it's primarily about protecting a user's private keys and facilitating (through hardware acceleration) a serious increase in the use of encryption to promote security and privacy.
"We're all fucked."
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
I like the extra random number generator chip as well as the encyption chip. I can imagine it would help e-commerce greatly and can be used for programs that require random number generation. Also hardware does not need to be modified. Only the motherboard. Microsoft wants each component to trust each and have it encyrpt everything. Its scary because its so proprietary. In the Xbox even the intel pentiumIII chip encyrpts and decypts data. Infact it will not run any assembly code unsigned. Spooky.
I hope IBM horries up and convinces other OEM's to use TCPA before they decide on using pallidium. Also IBM has been selling TCPA systems for close to 2 years now. SO yes they are not a threat to freedom or a drm sollution backed by hollwood.
http://saveie6.com/
The white paper explains why it would be easy to circumvent this chip if you have physical access to it.
DRM it is not.
They've released full GPL source code.
Looks like it could be useful.../p>
It's unfortionate to see White Papers, which in my opinion, should present fact, be so biased. If you read the author's section on DRM in the TCPA rebuttal you get a feeling like you're reading a post on slashdot.
Comments like: "I have no problem with people arguing against DRM; I agree completely." should not be there. It's ok to agree/disagree with DRM, but not in public documents with your employers name on them.
Just my $.02 CAN.
Jason
does this mean i dont get anymore free donuts???
While perhaps technically inaccurate as to the difference between TCPA and Palladium, I think the spirit of the attacks made against the platform are valid. While yes, perhaps TCPA doesn't directly enable all the horrible things we Slashbots complain about, but the paper is just passing the blame.
IBM says "this has nothing to do with DRM. In fact, it doesn't protect it from owner-tampering so it's not any great DRM replacement." Of course, they don't mention that it's more than likely that in the near future, a version of Windows will take advantage of it. Maybe the OS will encode all recorded music with your public key so it's unplayable on any other machine? Who knows, the possibilites really are limitless.
I wonder how many TCPA computers will be running Windows with Palladium enabled. Neither paper seemed to be catering to a very tech-head audience, so why make needlessly complicated distinctions between TCPA, Palladium, databuses, etc?
We all know that TCPA is meant to be trusted computing but i also see many issues with it. For ex, the integration of DRM into the whole equation by microsoft. I can easily envision them integrating it into their WMP 9 technology and preventing all those without TCPA access to the media. Next is the whole issue of what is "trusted". Is Open Source software trusted? What about compiling a custom kernel. Will that jeopardize the trustedness. Another issue i have is with a possible encrypted hard disk. Will criminals and terrorists sabotage their OS rendering the hdd unreadable?
----
Go canucks, habs, and sens!
As far as I can tell, it wouldn't be difficult to build systems running say, Win XP, with the hashes marking the trusted OS keeping any other OS from being loaded and successfully booted on the machine. Of course this is more like with a Palladium based machine. But this spec also allows it from what I got out of the paper.
Also, regardless of the author's opinion, a chip that enables DRM even sub-optimally is not the friend of the people.
Don't get completely up in arms about this is what is trying to say. Then he has an even better quote later:
Ahh...it's great to take stuff outta context.
My Slashdot account is old enough to drink...
I'm not sure why there seems to be such a mixed reaction to this news. From the talk that Lucky Green gave at Defcon X this past summer, I saw nothing but heaping stacks of badness to come from the TCPA. To quote the talk description from the Defcon website:
"This tamper-resistant Trusted Platform Module (TPM) will enable operating system and application vendors to ensure that the owner of the motherboard will never again be able to copy data which the media corporations or members of the TCPA don't wish to see copied, or to utilize the TCPA's software applications without pay."
Sounds like DRM to me.
I wonder if he is related to "Happy Gilmore"?
"And this is my boy, Sherman. Speak, Sherman." "Hello." "Good boy."
"Rather, it's primarily about protecting a user's private keys and facilitating (through hardware acceleration) a serious increase in the use of encryption to promote security and privacy."
In other words. It's no different than buying an add-on board with a crypto processor. Has anyone found out how much this will all cost?
This guy seems so concerned that the TCPA architecture does not *have* to be used for DRM, that he's ignoring the fact that it effectively can be. He talks about how easy it is to circumvent the chip (illegally, thank you DMCA, but moving on) since you have physical access to it. So its 'easy' to circumvent the chip if you have physical access? How easy? Do we need to solder our own computers to retain control of them? What happens when the TCPA architecture is absorbed into the CPU?
The fact remains that the average user has little need of the security features the TCPA is built for. Corporations, governments, organizations with information to keep confidential--sure, why not. But why implement it into consumer level PCs?
1) IBM doesn't care about DRM. In fact, this chip is completely unsuitable for DRM (and the white paper author was kind enough to explain why... protects you from SOFTWARE attacks, not hardware.)
2) The specs are open. There is a gratis GPLd demonstration driver/API for linux.
3) (My impression) is that it helps solve certain security chicken and egg problemswhen you want to do things like mount an encrypted hard disk, but not want to store the decryption key in memory.
4) Primary advertised use: for signing and verifying your OWN code, i.e. to protect yourself from root kits.
Black holes are where the Matrix raised SIGFPE
"... the people cannot be trusted" and "government knows best"?
Please tell me this is satire. This is the sort of thinking that nullifies democracy. Do you really think that Dubya knows best?
Is complete unsustantiated bs according to the second white paper, with a detailed analysis showing how much of it is pure fiction
Vote for Pedro
How about "why PDF?" *sigh*
"Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."
- Generate a public/private key pair, the private part never leaves the TCPA chip.. That's kinda nifty, because even if the bad guys get a root compromise on your system they still can't get your private key. They could however use the TCPA system to decrypt messages USING your private key though, until the root compromise was discovered and removed. So, kinda nice, but not a panacea.
- Put critical data (eg the encryption key for an encrypted FS) in a secure register that can't be accessed if "the operating system environment" is changed. I would need to spend some time reading the TCPA specification to understand exactly how they intend for this to work, but I'm dubious about this example. Once this data gets out of the secure environment, it's vulnerable to compromise, so in this case I don't see what this adds over keeping the key in the user's head, for instance.
Additionally, I'd be interested to see how the system copes with software upgrades. It seems like an impossible task to build a system that allows easy software installation but isn't itself vulnerable to accepting a trojan - and because the system's hardware the protocol can't be easily modified to deal with flaws.Presumably IBM has smart people who've considered this and think their solution is workable. In my copious free time maybe I'll download the spec and have a look... :)
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Does anyone know of a Unix utility to view PDF and/or PS files as text? Why can't these people publish a version on the web in HTML format as well?
IBM has shown that the 1st generation of TCPA is not a threat. They have not made any promises about the long term impact of TCPA. What happens when TCPA v2 comes out? Take this for example, my IBM sales rep. pushes SSA as the next great thing since SCSI. He went on and on about how IBM purposed SSA as a "SCSI v3 standard" and blah blah blah. So, we bought into it. Now IBM is talking about how Linux can be run on several IBM servers including the IBM RS/6000 F50 that we have. Ok. We try upgrading and sure enough the install CD boots... but there is no hard drives to install on. Of all 18 drives, Linux does not recognize a single one. But this is "True Blue" so we should be able to get the programming specs for the SSA controller. And after we get bounced around *SEVERAL* times, we are told that AIX 5"L" is "just like Linux or even better." The reality turns out to be the following:
/dev/random do not function as expected under AIX 5L ....
Programs written to use
Programs written to use the Pluggable Authentication Modules (PAM) API do not function as expected under AIX 5L
Programs written to the Linux VFS module API do not function at all under AIX 5L
The list goes on
So, IBM can prove that Linux runs on an IBM RS/6000 F50 with SCSI. But if you go to IBM's "Next Generation," anotherwords SSA, Linux is render useless and IBM promotes AIX 5"L" which falls short of everything we expect of a GNU/Linux distribution. Now IBM proves Linux runs on a current generation of TCPA. What does that mean in terms of being able to use Linux on the next generation of TCPA? Well, based on the source of this report, being IBM, and their handling of SSA technical specs, I'm pritty confident in saying that for the TCPA-NG we will be hearing alot more about how AIX 6"LL" has twice the "L" in the name as AIX 5 had so it "must" be more Linux-like.
Trust IBM and you will end up feeling "True Blue" or truely blue.
Reading the IBM paper and some of the propoganda against TCPA, I have to express my distaste for those who constantly insist on crying "boycott this", "ban that" whenever something like this is developed without bothering to actually find out what it is. First, there was DRM, which is bad, then Microsoft comes out with Palladium, and all these idiots ASSUME that it's Microsoft rolling over for Hollywood. Well, I don't like Microsoft anymore than the next geek, but Microsoft isn't about to do anything they think would cost them money, and so it appears that Palladium isn't any more of a threat to our freedom than TCPA. Besides, MS just joined an anti-DRM coalition! SO... then we learn about TCPA, and OF COURSE, people immediately begin yapping about how it's another form of DRM and making up "facts" out of whole cloth and doing nothing but confusing the issue.
Activism is a good thing when it HELPS something, but everything is clouded for no good end when people leap to totally uninformed conclusions and then make every activist look like morons along with them. The anti-TCPA people should be ASHAMED of themselves.
I'd have to say that my opinion of IBM went up. They seem to be making an honest effort to show exactly what TCPA is. I admit I have not read the documentation, (my mind has shut down for the night). But it seems like many of the companies, (IBM and AMI for instance), are working to let people know that TCPA is nothing more than a tool available to people who want to secure their computers and not a tool meant to secure other people's content on your computer.
I do security
"We're all fucked."
To a board full of socially challenged geeks, TCPA must look like a godsend.
Can I have the private key?
If yes, no problem; this is probably not a Bad Thing, and may even be a Good Thing.
If no, time to buy a Macintosh.
Sigs are like bumper stickers.
That is why you should read a technical analysis on TCPA and not biased FAQs... even better, read the TCPA open specification at the trusted computing homesite
Hardware solutions to DRM issues are dangerous in any form, because they are controlled by the very few. DRM is a legitimate concern, which deserves a solution. However, that solution should be based on free software, because free software is not and cannot be abused by a self-interested power-mongering minority.
The only private key that cannot be cleared and arbitrarily loaded by the owner is the endorsement public key pair, which possibly is created on the chip at manufacture time, and the public part recorded by the manufacturer.
So they want to install a secret key in my computer that I'm not allowed to access.
If you want endorsement, you have to have that key. If you don't want endorsement, you
can disable all access to the key.
Not good enough. What if I don't want endorsement, but the software I'm running requires it? What I need is the ability to read and change the endorsement key so that I can falsely endorse my system to be something that it is not (emulators, anyone?). But of course that would defeat the whole purpose of endorsement, which is to allow others to control what I can and can't do with my own machine.
Maybe I'm misunderstanding this, but TCPA seems to work by encrypting files (including files for booting) and then refusing to decrypt them if the system (hardware, OS) is different from when they were encrypted. These whitepapers point out that you can turn off the encryption or set whatever you want as the 'safe' system state.
The problem is that if you are using the encryption, any change in the system will lock you out of your encrypted files. If a virus installs itself on your computer--even if it's only designed to display an irritating popup message--you could be locked out of your files, or maybe even booting the system, until you restore everything from a backup.
That doesn't sound like a good idea for home PCs, especially not if they're running Windows.
-- . . ramblin' . . .
If I only had some mod points, you would be headed straight for "FLAMEBAIT!"
Microsoft to Dell: could you please ship our new paladium board in your computers.
Dell to Microsoft: Fuck off if word gets out that you cannot copy stuff on one of our machines we are certainly ruined.
Microsoft to Dell: Do it or else
Dell to Microsoft: Fuck you we are shipping Lindows
Got Code?
If people want to have something like this just put the private key on a USB dongle. I can remove the damn thing this way if I wish, my decision. This is no different than the hardware dongles software manufacturers sometimes use only this on is permanatly attached and cannot be removed.
Got Code?
It is our choice to adopt something like this. Wether it be palladium or TCPA, we as the end consumers of the technology can make it possible, or impossible for this type of technology to proceed. The adoption of this technology relies very heavily on consumer adoption. If we don't like it we won't have to buy it.
Before jumping to conclusions about "bad" and "good", why don't we take a good, hard, objective look and evaluate the implications from all sides, and say "Yes, this is something that is worth while." or "No, this isn't helping me or the private development community at large." Only then after having an informed, justtifed position can we attack the moral (and it is) framework of such a project.
If they build it, you don't have to come.
Please, let me know where to get the chip?
When modding this creature up, please check his posting history. He's a known karma whore and troll.
Can you show me Palladium that doesn't need TCPA?
Can you show me any great customer demand for TCPA other than Palladium? Are there not other technologies that would solve customers needs without being TCPA? I would think that a card with random number generator and an a cpu dedicated to encryption would solve give you everything TCPA would give to Linux.
My understanding of TCPA is basically that you
can have many people do the digitial signatures. The way I read it is that even if your software
was signed and trusted by the God if a media
company doesn't have God's software on their approved list then you will not be allowed to view their movies or music.
--JayR
The page is really helpful in understanding what TCPA is. However, there is one point that I don't quite understand. The Why TCPA document says:
Fine, I can have data for my Linux partition that is unreadable even if my naughty sister boot a Windows XP on it. Seems something that I might want. Then later in the article, it says:
I really don't understand the "trusted boot" functionality is immune to exactly the same argument. You can seal important data under a PCR. But if you upgrade your kernel, you must unseal all such data, upgrade your kernel, seal it all again. If somehow you forget to do this critical step, or if a hacker succeed in modify a single bit of your OS boot image, your data is lost forever. Is this what the function really supposed to do (the data is so important that losing it forever is better than having somebody else getting hold of it), or that I have some seriously misunderstanding of that portion of the paper?
Have all of you gone insane?
TCPA...DRM...Palladium? What the hell's the difference in the end? I cannot believe that anyone is supporting ANYTHING even remotely resembling any type of DRM or trusted computing scheme.
Have we really lost so much focus that we are willing to give up our RIGHT to do whatever we please with the data that resides on our drives? Even if it's a small concession, the road to hell is walked one small step at a time.
A proposed solution to this problem is to encode the private key with a passphrase. Unfortunately, almost all the systems that do this use software to read and check the passphrase, making it simple to intercept.
How we know is more important than what we know.
It can be used to boot a secure OS, yes. But it won't prevent you from doing it if you want to (especially since you get to define which OS is valid; this is an advertised feature)
It also provides a way to do things like verification hashes or cert checking outside the CPU. You can stick a private certificate in it and sign/encrypt stuff all the live long day without worry that your system gets rooted and your private key or ipsec.secerts compromised.
The hacker would have to come into the server room and remove the chip, at which point they have a slim chance of opening it up and getting the key out (...its not hardened). But if they can do that, then you're screwed anyway. (See the previous article on AT&T and tumbler lock vulnerabilities)
Thats basically what it does. Also, a builtin RNG in case you don't have an i810 chipset.
Black holes are where the Matrix raised SIGFPE
Somehow I believe there will always be a demand for open hardware. Even if Microsoft's wet dream of everyone having Palladium embedded in their notebook computer, TV, dish washer, and cerebral cortex comes true, there will always be demand for a piece of hardware that can run code without Bill Gates' say-so.
And where there's Demand, someone will step up to the plate and Supply.
The only risk here is government interference. In America's case, that seems to be a big risk. Look at the V-Chip. Rather than let the open market handle things, it has become law that all American televisions have electronic parental controls built in. I have to pay for that crap because I *might* have a kid one day and I *might* want to keep that kid from watching pr0n.
Hell, maybe if our tax dollars have to go towards enforcing crypto laws, maybe they'll cut funding to the War on Drugs, and if I couldn't use my computer for what I wanted to I could twist up a big doobie and get baked in peace and not give a crap.
By itself, a security coprocessor is no different than using the PIII's serial number to create a unique hash and processing encryption on the main CPU.
Imagine you already have this TCPA processor on your board. You download the newest RIAA-approved secure media player and start downloading tons of songs. The media player wants to use your TCPA processor to encrypt the songs while you're downloading them so only your PC can play them. Evil, yes, but it can be done TODAY on a PC without a dedicated TCPA processor.
The application is happily encrypting its audio, however, in the background you're running an application that acts as a virtual soundcard and you're capturing open, unencrypted audio and saving THAT to your hard drive as well. So much for TCPA.
This is where Palladium comes in, it would not allow you to run a virtual sound card driver. Palladium is about a trusted secure enviorment, which requires the cooperation of the BIOS (ensure the OS that is about to be booted is trusted, and possibly in the future BLOCK booting of non-trusted OSes entirely), the OS, the main processor (for secure memory protection) and the video and sound cards. It is highly likely implementations of Palladium systems will not even HAVE a dedicated TCPA chip that can be easily attacked and disabled - the features will be built right into the main CPU.
---
DRM is like antifreeze, to the MPAA/RIAA it's sweet, to the consumers it's poison.
This chip sounds like it's very well suited to DRM. The RIAA will know what hashes go with WindowsXP Service Pack 10. They can encrypt a key under that hash and, separately, under other approved hashes. Then they encrypt all their content with those keys. Then they sign a deal with MS blocking unauthorized programs from accessing the encrypted keys on Windows.
As a result:
- You can only decrypt the keys on Windows.
- On Windows, only RIAA approved apps can get the key file in order to decrypt it.
That's my understanding of the Evil Master Plan, and nothing in the whitepapers showed that it couldn't happen. Turning off TCPA would just mean that you couldn't access DRMed data at all.-- . . ramblin' . . .
Why cant we just use smart card technology instead? That way you get the benefits of TCPA without having to get a new PC, and its not perminant enough to make it work for DRM.
http://www.kaosol.net/~mackys/irreg/
The most obvious use is to authorize my connection to a remote server. If the private key is safely locked away on the chip then I can be assured that only my machine can connect to the remote server with that identity.
Another use would be to sign emails. Again, I can be assured that any email that is signed with a key that is safely locked on the chip could only have been signed by someone using my machine.
In fact, I'm hard pressed to come up with a way that this chip could be used to do DRM under Linux. Can you?
How we know is more important than what we know.
You know, what PGP and GPG champion but don't provide.
I think my point is FEATUREWISE it doesn't provide anything software can't in terms of copyright protection. It does provide refutability but it has to be supported in software (which can be hacked, i.e. ignore the hardware's suggestions). To circumvent, first change the software. Then flash your TCPA with the new checksums for the hacked OS/DRM layer. Reboot, and voila, it trusts whatever you say.
Black holes are where the Matrix raised SIGFPE
why do you need to know the private key? So you can give it to someone else? That's stupid, and completely defeats the purpose of asymetrical encryption. As long as the hardware does what you say then you have access to your private key, and that's all you ever need.
How we know is more important than what we know.
Let me get this straight:
IBM and the hardware manufacturers are saying: "TCPA is just a gun! It can be used for good or evil purposes!"
Microsoft is saying "Palladium is just a bullet! It can be used for good or evil purposes and it stops piracy which is illegal! Do not look behind the curtain marked 'this machine kills linux'!"
The content industries are saying "DRM is another kind of bullet! It can be used for good or evil purposes and it stops piracy which is illegal! What is this 'fair use' you speak of?"
The whole bunch of them are saying "We are forming a club. All club members will communicate with secret decoder rings which you are perfectly free not to use however don't expect to be able to join the club without using them!"
From the standpoint of Linux IBM's involvement is great; its keeps Linux in step with TCPA and perhaps even Palladium if Palladium turns out to be open (which it very well might be). From the standpoint of Linux users I don't think this is good.
The whole reason the GPL was created was to create software which saw computer users as a community of citizens assisting one another. not a consummers of software services. That is it was designed to encourage the free sharing of information in a communal fashion. TCPA/Palladium is designed to encourage the restriction of information to the appropriate parties. If Linux were to achieve 100% of the computer operating systems market in a world of lock down systems, locked down data, with virtually nothing in the public domain that is no victory for the ideals of the GPL.
no, you mean "normal users of windows" which is actually almost offense to me. Most users of Linux make ssh connections all the time. Some of us have even had the misfortune of having our RSA keys stolen. Meanwhile, "normal users" of both Windows and Linux make thousands and thousands of "trusted" connections every day: SSL. And they send insecure little numbers over them: credit cards. TCPA could be used for a secure digital cash system, but it wont happen unless it is ubiquitous.
How we know is more important than what we know.
My Father has one of these IBM laptops. Hasn't restricted anything nor has it done anything useful far as I know.
All the hardware companies are pulling this tactic. "Oh we are just putting TCPA capabaility" its that evil Palladium/DRM that is going to be the problem. You heard the same thing from AMI. I think that does represent IBM's position.
1) Hardware companies "just provide" TCPA
2) OS companies "just provide" the capacity for trusted apps
3) Trusted ap makes "just provide" the ability for people to send you data securely
4) Digital content companies are just taking advantage of existing technology to prevent unauthorized redistribution
5) Fair usage doesn't exist anymore in practice
The fact that 1 enables 2 enables 3 enables 4 enables 5 is supposed to escape the public. So when we have a world were fair use has been completely repealed there isn't going to be anyone to blame.
actually, all the code is GPL, which you'd know if you read the article.
How we know is more important than what we know.
Okay, so TCPA is not evil, as I had been led to believe. I have a nagging question about it, though, that I need answered before I consider it a Good Thing.
Let's say I'm sitting and twiddling my thumbs, or serving rather a lot of MP3's to the Internet at large, or something, and my computer crashes. Uh-oh, the hard drive can't be read. Looks like I need to boot from another drive to fix it. Trouble is, when I try to do so, TCPA interrupts and tells me I'm trying to boot from a different system, which isn't allowed. How do I repair my drive?
Of course, as a Mac user, I guess I don't have to worry about this much anyway (Apple still hasn't signed up for TCPA, right?). Besides, maybe in the Wintel/*nix-other-than-OS-X world I know so little about, there's a simple way to overcome this. But wouldn't a simple way to overcome it involve using software to make the switch? It's either that or jumpers on the motherboard, right? So the question stands.
Somebody fill the void in my brain! I long to know!
I found the meaning of life the other day, but I had write-only access.
They're both things that clueless people like to whine about on /., while people who actually know something about them are perfectly happy with. :)
:)
Interestingly, while it used to be Linux users laboring under the delusion that PDF was a closed format who would whine the loudest, nowadays it seems to be mostly MS users who snivel about PDF files. Of course, having used Acrobat, I can sympathize a little, but only a little. Switch to Linux, or get a copy of pdf2ps and ghostview, and shut up!
Really, if they're going to release a 322-page specification with that requirement, they're in for trouble.
Did I just read that IBM put a dedicated chip in thinkpads that handles encryption / decryption? Yeah, yeah, protecting private keys is neat, and random number generation is certainly a worthy pursuit, but an encryption / decryption accelerator would be wonderful. Perhaps e-mail client programs will start incorporating hooks for invisible background encryption... or the files on your hard drive will all be encrypted by default, all of the time (don't fry your processor). Sure, that sort of thing could facilitate a protection layer fostered against us by the boys in blue, but only on Windows.
Ok, this is wild speculation, as the current TCPA only calls for encryption / decryption of the public key. Still, though, a dedicated chip that accepts a key and a stream of data, and spits out a stream of data, could be very useful for working seamlessly with encrypted files without overloading the processor (or having a higher level garble your data in the attempt).
In other news, we're *still* waiting for invisible encryption in e-mail messages. This is a good first step to protecting your most valuable data, but I would hardly call it an entirely safe platform.
-C
This Sig is a mnemonic device designed to allow you to recognize this author in the future.
I personally am not too impressed with the "configuration seal" parts of the chip. Frankly, I could do without that.
How we know is more important than what we know.
Quote:
The public key functions are very similar to IBM's original ESS chip design (which already has GPL'ed drive code in active use by several projects) ...
Note that "GPL'ed" is used as a verb (OK, participle). Also note that there is no footnote or explanation. We are supposed to know what the acronym "GPL" stands for (which, of course, everyone on Slashdot will know). The paper was not written for a very wide audience.
Still a good paper.
IBM's whole arguement on TCPA and privacy hinges on the assumption that software wont simply require an endorsement key, presumable from consumer pressure.
... I say they are just naive, and the engineers who are giving software companies the tools to abuse them are selling their soul (if they have one to begin with).
The moment you need to expose the endorsement key to be able to run the latest version of windows privacy goes right out the window for a great number of users. One might say that those users are stupid for letting it happen
If TCPA did not have endorsement keys everything would be hunky dory, as long as it does have them suggesting you can "simply" turn access off is a misleading arguement.
I'm glad to see IBM directly address TCPA issues. Their explaination of how TCPA works is better than what I had for the AMI/Slashdot interview.
I'm also happy to see a TCPA/TPM driver for Linux (was wondering when sopmebody would get around to that).
Brian Richardson - AMI
how do you know the chip isn't backdoored to allow IBM (or microsoft, or the feds) to get your keys...?
If there is any possible way for application software to be able to determine with certainty, that an actual hardware TCPA chip is present instead of software emulation, then I smell a rat.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Firstly I haven't read the article, but I would like to raise an issue that has been touched on by previous posters but never properly addressed.
OK, now, if you have a chip on your MB which contains your private key, you can only decrypt stuff with that chip because it has your key in it.
So, say I encrypt naked jpgs of my girlfriend (ha ha I wish), then the MB decides that it is going to blow its caps today. I have naked jpgs on my hard drive, which I can put in another computer and read, but can't decrypt!
Doesn't it make a nonsense of backing up your data if it's encrypted in the backup? You can't backup your private key because it's hidden in the damn chip.
Someone mentioned something about "migratory keys"- I know that I could just look this up, but in the great spirit of 'Ask Slashdot' I will just say that I don't know what a 'migratory key' is here, and hope someone fills me in...
graspee
>> user's private keys and facilitating
>> (through hardware acceleration) a
>> serious increase in the use of
>> encryption to promote security and privacy.
>
> In other words. It's no different than
> buying an add-on board with a crypto
> processor. Has anyone found out how much
> this will all cost?
Is it? I don't mean this as a troll -- I don't think you'd get the same protection of user private keys with an add-on board as with bios-level verification (which I think they're talking about; flame me in all caps if I'm wrong.) Talking over the bus to an cyrpto-board through a general-purpose interface and talking to another chipset through specialized instructions strike me as two different things. You'd probably hit Rice's Theorem with the first; the second, you could trivially weed out for "non-verified" code. I don't know, whatever. Fucking computers.
--Drunk and Reading Slashdot
"Whatever happened to fair use?"
-- Duff-Man
But it doesn't facilitate DRM at all; the private key never leaves the chip, and it isn't set until the user sets it. This makes it useless to anyone *except* the user; the MPAA doesn't have the key or even the chip. The user, at least, has the chip.
They don't need your private key; they need your public key. All they need to know is that the private key is unique to your machine. Here is why:
1) I give you a file encrypted using the public key from a trusted application running under a trusted nub/tor on your machine using a valid TCPA.
2) because the tor/nub key is based on your TCPA key its only usable on your machine's trusted environment and not anyone else's even if they have exactly the same software
3) because the tor/nub key is based on the tor/nub its only usable when running under the same tor/nub which means I can confirm that the OS isn't running on a virtual machine. That means I can trust the OS.
4) Because of the trusted OS I can control what applications have the last part of the key and those can confirm with the OS that they are running in a trusted mode.
That's how DRM works. You bootstrap trust. As long as you the CPU won't let emulate a call to the TCPA chip and the TCPA chip generates the keys for the tor/nub you have a signed hardware/software environment.
OTOH, if you patch just two bytes in the SRM for Win2K , you can take over the machine. TCPA isn't about encrypting the operating system, it is about protecting code, whether Linux or Win, or whatever.
The public-private key pair thing is addressing the problem of ensuring that the private key never gets where it might be read. For example, a private key on a passive dongle must be read and used by the processor, so it may be intercepted by an eavesdropper It is harder if the key is only seen by a dedicated processor (GSM SIM cards work a little like that but the encyption is shit).
Of course, a hardware protected SRM may be used for a number of different things, validating the OS, encrypted file systems and SSL but unfortunately also DRM.
The article makes it clear that you will always be able to run code of your choice before any code produced for DRM without the latter detecting it, which is A Good Thing(tm) because the former could then modify the latter in anyway, again without the latter detecting it.
It also makes clear that the private keys stored on the chip will be possible to extract, but only if the hardware owner enables it.
As for the endorsement key, it's a way for the TCPA producers to make money by selling licences to the list, so it's most likely only a matter of time before they will be using them. Some producer could take a stance by not recording it, but once media producers starts locking their media to these list, people might actually start to want to have it, because it's what lets you play the media. This is A Bad Thing(tm).
However, due to the good thing above, if you have access to your own private endorsement key, you could give it to someone else, thereby effectively letting that person assume your identity of these specific keys (you could still use the other keys you have generated yourself for security). A good enough software would be able to switch between different keys at will (of the user).
So what it really comes down to is: Is the private endorsement key extractable from the chip by software means?
This will be a likely turn of events, as if someone enables this along with the software that lets you switch keys, people will start wanting it.
All that is left is whether this would be a legal thing to do under the DMCA/EUCP. If no, this is a DRM chip. If yes, it is not (a successful one).
Exactly. Sure, it is an open technology. Linux can take advantage of it. But don't assume it can't be used against Linux users.
I see the generation of TCPA-compliant laptops preloaded with Windows DRM/OS as exhibiting characteristics:
- Uses TCPA hardware to only allow Windows DRM/OS and the OEM recovery CD to boot.
- No way (short of a mod chip) to get around the aforementioned limitation.
Thats great if Linux can take advantage of the TCPA hardware, but thats no consolation if you aren't allowed to install Linux on the machine in the first place.
If you want Linux on one of those machines, you'll have to buy it with Linux preinstalled or without an OS at all. We all know how likely it will be that we are offered those options, don't we?
Try getting a refund for software that you can't remove from the machine.
I'm truely afraid that I won't be able to write very many more new guides to submit to linux-on-laptops.com
According to this paper, the TCPA chip is on the LPC bus and is accessed by I/O mapped registers. LPC is the "Low Pin Count" bus, a 4-wire bus designed as a cheap way to link the CPU to low-bandwidth stuff like keyboards, serial, parallel, floppy, and maybe USB ports. It maxes out around 5 MBytes/sec -- nowhere near enough to keep up with a hard disk or a 100Mbit link. See the LPC bus spec if you want the gory details.
TCPA chips sure looks like a bloody dongle. Identical functionality. I simply do not see any legitimate use other than DRM/licensing (and spare me the encryption speedups).
Geeze, I may have risen to the bait of a troll, but that hardly makes me a troll.
Let's review: an article is posted pointing to white papers explaining what TCPA is, and detailing how it's clearly useless for DRM. Kevitt responds, "TCPA...DRM...Palladium? What the hell's the difference in the end?" If he'd read the white papers, he'd know the answer to that question, but somehow, he gets modded "insightful". I point out one of the key reasons that TCPA will be all-but-useless for DRM, quoting one of the white papers, and I get modded as a troll. Sheesh!
Let me just say, as a member of the Debian project, I'm sure that Debian will have support for IBM's TCPA-enabled systems before long. Not because we want to prevent you from doing whatever you want with your system, but because we want to allow others to prevent you from doing what you want with their systems.
From the whitepaper:
"Protection of sensitive authentication data, such as passwords will become critical for
electronic business to succeed."
Passwords are *user* specific things, not machine specific things.
Storing them in a vault on a single machine means they are stored in the wrong place.
This is a lie.
From the rebuttal whitepaper
-----------
"When you boot up your PC, Fritz [the TCPA chip] takes charge. He checks that the
boot ROM is as expected, executes it, measures the state of the machine; then checks
the first part of the operating system, loads and executes it, checks the state of the
machine; and so on."
This is completely false. The TCPA chip doesn't execute anything. It accepts request data, and replies with response data. In the IBM version,
TCPA sits on the LPC bus, using I/O mapped registers. The TCPA chip does not and
cannot control execution!
-------
This is a misdirection, the original comment was about the TCPA system in its entirity, the response talks only about the chip part of the TCPA.
Microsoft is not rolling over for Hollywood. They see this as an opportunity to make money (by getting a stake in the online distribution of content), increase influence (by becoming the gatekeeper to such distribution), and destroy Linux (by effectively locking it out of future hardware, content, and/or network connectivity) at the same time.
Microsoft did not join an anti-DRM coalition. Instead it joined a group that wants to push its own version of DRM to the exclusion of all others. They are only anti-DRM as long as they do not own the DRM.
Any system that has the *potential* to destroy competition (by Linux, in this case) and strengthen the Microsoft monopoly even further must be fought against, even when that system also has beneficial possibilities.
Here's another misdirection, again he is rebutting a valid comment.
-------
The comment he is rebutting:
"You might prefer not to have to worry about viruses, but neither TCPA nor
Palladium will fix that: viruses exploit the way software applications (such as
Microsoft Office and Outlook) use scripting."
His rebuttal:
While TCPA cannot prevent stupidity
in software applications, it definitely can control the resulting damage. In particular,
no virus can steal a TCPA protected private key.
How can it, if the private key is
generated in the chip, stored on the chip, and never leaves the chip?
Again the comment he is rebutting:
" Seen in these terms, TCPA and Palladium do not so much provide security for the
user as for the PC vendor, the software supplier, and the content industry. They do
not add value for the user, but destroy it."
And his rebuttal of this:
Personally, I find the ability to protect my
private keys, and to protect my encrypted data very important and very valuable.
-------
The misdirection here is in the last paragraph. The keys he is talking about are not *your* keys. They are not specific to *you* you do not carry them around from PC to PC and you do not have access to them.
Your keys (things like your passwords and PGP keyring files) can be stolen when they are entered in the computer just as before.
From the whitepaper, again there is the confusion between *me* and *my computer*:
------
"Protection of user authentication keys
Given the large number of vulnerabilities in client system, and the trend of hackers to
target client machines looking for passwords, it is vital to provide some way to protect
sensitive authentication information such as passwords and private keys. TCPA provides
exactly this protection.
A user can generate an RSA public/private key pair on the TCPA chip. The private key
can be configured never to leave the chip."...
-----
Right, stop right there. If my private key never leaves the chip what use is it to me? It identifies my computer not me.
Whoever is at my computer, if they intercepted my login has all *my* private keys and for all purposes *is* me.
I meanwhile can move from computer to computer, but I cannot identify myself, because those private keys are on my home computer and can never move.
I just read the TCPA faq on the NOTCPA site http://www.notcpa.org/faq.html
,MPAA and MicroSoft are dreaming of !
First i was surprised by the differences with the IBM papers...
Then i started to write the proof that TCPA is only useful for DRM (and should be boycotted loudly):
In the IBM papers, it is written that TCPA can be used to generate a private asymetric key that can no longer be used if the system changes (hardware or software), and that noone can read, even the owner of the computer
The associated public key can then be used by some vendor to encrypt content it sends to you, so that only your own computer TCPA chip can use this content.
this is exactly the perfect DRM scheme that the RIAA
On the other hand, without any TCPA, linux systems already have security features (posix capabilities, and now LinuxSecurityModule) to ensure that noone, even root, can tamper some files (like the kernel and other main system files). LSM jail features can ensure that an internet program will never access some important private files on your harddisk.
Right now , without any TCPA or linux kernel tweaking, you can use a bootable CD-rom or a bootable read-only floppy to check your hard-disk system files integrity each time you reboot it.
Conclusion: TCPA offers nothing important for Linux users, but offers a lot for DRM interested corporations !
My question is to the knowledgable out there:
Can the SSH-suite be extended in such a way that it detects the presence of the TPM on board and use it for its own good?
And now for my comment:
This (I mean the article) is good news in my opininon. Instead of reviling new technology because the original intentions were focused on something bad, look for ways to embrace it and use it for other means. Means that are good. Or, if that fails, develop countermeasures. Just taking the stance "that's just evil" does not help anyone.
yes i know it'll bring benifits in terms of security etc, but as i'm probably misquoting alan cox here: its not your computer if you cannot dictate what you can and cannot run on it, it becomes someone elses. does this mean the end of 'free' technology? i think, the only alternative left might be apple, god i hope they dont go the DRM route
dybia felly dwi a hampster (i think therefore i am a hampster)
yeah i personally dunnot need an fritz chip. cauze it's my hardware. so i can do with it what i want, if i want rto throw it out of the window i can. if i want to have tcpa i can, but i dunnot wan't.
.
,cauze of trust. maybe tcpa but with own system's running on top so each goverment has it's own linux distro , but they need to build an own trust system based on that. and have to think about data-recovery/managibilty/migration which will be a pain in the ass with *machine* key on the chip .
I' going over to PPC processors this year.cauze intel with the "customized instruction set"
home use
on my opinion ms just want's marked share , as usual. and trust me i can live without a ms system @home , i dunnot need the fancy micky-clicky things and super secure data,as promised by palladium , ah and no virrii
for buissense users i see 2 kind of users American's and the rest of the world -Buiseness as usual- while americans have fritz hollings bill which makes it non-optional to sell non-tcpa hardware in the united states. and the rest of the world which mostly means, if Buissenes Case is big enough , we use PKI n cipher boxes just pure data managbility/recovery/migration n so on.
u dunnot give trust to someone u don't trust.
or as seen in the last past day's if someone calls u OLD EUROPE, why should u do that ?
so all big pki solutions are private one's in a company or a sub-company of an holding is managing the pki for the company.
i guess also that's the ideear behind PKI.
for me the whole thing about enabling tcpa is an govermental affair -fritz hollings bill- all further techhnologie build on such a set is commercial one.
i mean think about the size , every desktop has such an chip. so for software vendors it's an easy ground to build up alliances with vertical markets and deploy an propietary protocol. and it's an good cash-cow. cause it's security based on the machine not on the user as most user's in company's are roaming
tcpa will be an enabler for machine based security.
so the only scenario is see for machine based security , are home-users with one machine, mobile Phones, Smart-Devices as the the coffe machine that surfes the internet for your millions of millions of coffe flavors , that will bring man kind to an definitive *über*position.
and game-devices like xbox,sony,nintendo.
as for govermental use i dunnot think that goverments will trust per default.That would be absolutly blue-eyed if someone thinks that.
I dunnot even think any goverment will use palladium
of caurse the tcpa chip itself, doesen't evolve such scenarios per se, but it's an enabler. that as an defined API which is under the GPL IT MUST BE UNDER GPL CAUSE OF FRITZ HOLLINGS BILL
so nobody should only think of to say, that we made it just GPL for *u*
And its on every machine selled.
So technicly the tcpa chip, is a little tiny thing which isen't evil.
technicly nuclear fusion is also a little tiny thing which isen't evil.
IBM is doing pretty much what every other business does, downplaying the bad and promoting the good sides of their product.
Soon, you will have TCPA/Media Center PCs. I'm pretty damn sure they *will* contain an endorsement key (that Microsoft will have, probably in the licencing agreement for making them), that you can not gain access to (except for a hardware hack), and that you can not emulate. This key will verify your BIOS, your Windows Palladium Media Center, and your DRM-crippled Windows Media Player. Or maybe they'll stage a few "licenced" players to create the illusion of choice.
And in the next level, I've heard that TCPA will be internal to the processor. Goodbye even to the hardware hack.
Saying the TCPA of the IBM machines doesn't have an endorsement key is saying, "yes, we're pointing this assault rifle at your consumer rights, but we haven't loaded it yet". Then when people "have to" have an endorsement key to get programs working, they can blame it on consumer demand.
Kjella
Live today, because you never know what tomorrow brings
How do you know $TLA cannot come in and press magic combo a,b,up,a,start and get the chip to spout out your keys? All this sounds so much like distributed key escrow (remember Clipper?) that it's frightening.
Part of what IBM seems to be marketing is a prioritary encryption key generator, but I think we have already learned from the seed prediction of the SSL for Netscape v2 that prioritary encryption key generators tend to weaken the strength of the encryption. No where in the entire page does it explain who was permitted to audit the firmware. While the driver is GPL, there is still a great deal of trust that the user must put in the closed source firmware when using the driver.
Exactly why do I _want_ these chip[s] on my new mainboards?
;o)
It sucks case-space, and waste's Juice. (v/r=i)
I _want_ to add chip[s] to my mainboards that have things like
a TB of memory, or say a "Spare CPU slot (tm)" (sic)
In fact why not just add another CPU?!
If the white paper's _intentions_ are to be believed as stated,
this eFFing "Kradical new Chipp0r"(tm) does not need to BE
physically soldered onto the "eFFing mainboard" (tm)
They can make it a self contained appliance that plugs into the wall,
and plugs into the box (via serial, parallel, or usb)
Then when *I* _want_ to do some eCommerce or some 31134
crypto to my friends then I can plug the little bugger in,
do my Biz, then disconnect0r the SOB!
But noooooooooooooo!? that's not the True Evil Intentions.
They *HAVE* to put this BOFH on the MB's now,
cause they know folks do not take change easilly,
So they desensitize you to this crap now.
IBM, test away, research away,
hopefully someone will break it in the research lab
*BEFORE* they roll the crap out the door.
Maybe the Genius's at SuSE or United Linux
can smoke-check that lil-bugger and prove that it's flawed.
But I digress, what a whoring plethora of bullcrap TCPA is.
I think I meant plethora of whoring bullcrap.
Love Music? Got a Band? Are you a Label? http://garageradio.com
I wonder with all this new dependency on the TCPA/DRM chip, if there will be a renewed surge in open source BIOS projects -- those that ask you "do you want to use the chip or not?"
Suncoast Linux - Sarasota, FL
From: "Bill Gates"
i beMe.asp?lcid=1033&id=155 to subscribe. If you don't wish to hear from us again, you need not do anything. We will not send you another executive email unless you choose to subscribe at the link above.
.NET through an incredibly vigorous design review, threat modeling and security push, and in the coming months we will be releasing other major products that have gone through our Trustworthy Computing security review cycle: Windows Server 2003, the next versions of SQL and Exchange Servers, and Office 11.
2 3security2.asp to help you make your computer systems more secure.
Date: Fri, 24 Jan 2003 07:08:30 -0800
To: <vegetablespork@localhost.io>
Subject: Security in a Connected World
Jan. 23, 2003
I'm writing to you about an issue of particular importance to those of us who routinely use computers in our work and personal lives - making computing more secure. Before I share my thoughts about this in more detail, I want to give you some context on why I am sending this email.
This is one in an occasional series of emails from Microsoft executives about technology and public-policy issues important to computer users, our industry, and anyone who cares about the future of high technology. If you would like to receive these emails in the future, please go to http://register.microsoft.com/subscription/subscr
******
As we increasingly rely on the Internet to communicate and conduct business, a secure computing platform has never been more important. Along with the vast benefits of increased connectivity, new security risks have emerged on a scale that few in our industry fully anticipated.
As everyone who uses a computer knows, the confidentiality, integrity and availability of data and systems can be compromised in many ways, from hacker attacks to Internet-based worms. These security breaches carry significant costs. Although many companies do not detect or report attacks, the most recent computer crime and security survey performed by the Computer Security Institute and the Federal Bureau of Investigation totaled more than $455 million in quantified financial losses in the United States alone in 2001. Of those surveyed, 74 percent cited their Internet connection as a key point of attack.
As a leader in the computing industry, Microsoft has a responsibility to help its customers address these concerns, so they no longer have to choose between security and usability. This is a long-term effort. As attacks on computer networks become more sophisticated, we must innovate in many areas - such as digital rights management, public key cryptology, multi-site authentication, and enhanced network and PC protection - to enable people to manage their information securely.
A year ago, I challenged Microsoft's 50,000 employees to build a Trustworthy Computing environment for customers so that computing is as reliable as the electricity that powers our homes and businesses today. To meet Microsoft's goal of creating products that combine the best of innovation and predictability, we are focusing on four specific areas: security, privacy, reliability and business integrity. Over the past year, we have made significant progress on all these fronts. In particular, I'd like to report on the advances we've made and the challenges we still face in the security area.
In order to realize the full potential of computers to advance e-commerce, enable new kinds of communication and enhance productivity, security will need to improve dramatically. Based on discussions with customers and our own internal reviews, it was clear that we needed to create a framework that would support the kind of innovation, state-of-the-art processes and cultural shifts necessary to make a fundamental advance in the security of our software products. In the past year we have created new product-design methodologies, coding practices, test procedures, security-incident handling and product-support processes that meet the objectives of this security framework:
SECURE BY DESIGN: In early 2002 we took the unprecedented step of stopping the development work of 8,500 Windows engineers while the company conducted 10 weeks of intensive security training and analyzed the Windows code base. Although engineers receive formal academic training on developing security features, there is very little training available on how to write secure code. Every Windows engineer, plus several thousand engineers in other parts of the company, was given special training covering secure programming, testing techniques and threat modeling. The threat modeling process, rare in the software world, taught program managers, architects and testers to think like attackers. And indeed, fully one-half of all bugs identified during the Windows security push were found during threat analysis.
We have also made important breakthroughs in minimizing the amount of security-related code in products that is vulnerable to attack, and in our ability to test large pieces of code more efficiently. Because testing is both time-consuming and costly, it's important that defects are detected as early as possible in the development cycle. To optimize which tests are run at what points in the design cycle, Microsoft has developed a system that prioritizes the application's given set of tests, based on what changes have been made to the program. The system is able to operate on large programs built from millions of lines of source code, and produce results within a few minutes, when previously it took hours or days.
The scope of our security reviews represents an unprecedented level of effort for software manufacturers, and it's begun to pay off as vulnerabilities are eliminated through offerings like Windows XP Service Pack 1. We also put Visual Studio
Looking ahead, we are working on a new hardware/software architecture for the Windows PC platform (initially codenamed "Palladium"), which will significantly enhance the integrity, privacy and data security of computer systems by eliminating many "weak links." For example, today anyone can look into a graphics card's memory, which is obviously not good if the memory contains a user's banking transactions or other sensitive information. Part of the focus of this initiative is to provide "curtained" memory - pages of memory that are walled off from other applications and even the operating system to prevent surreptitious observation - as well as the ability to provide security along the path from keyboard to monitor. This technology will also attest to the reliability of data, and provide sealed storage, so valuable information can only be accessed by trusted software components.
SECURE BY DEFAULT: In the past, a product feature was typically enabled by default if there was any possibility that a customer might want to use it. Today, we are closely examining when to pre-configure products as "locked down," meaning that the most secure options are the default settings. For example, in the forthcoming Windows Server 2003, services such as Content Indexing Service, Messenger and NetDDE will be turned off by default. In Office XP, macros are turned off by default. VBScript is turned off by default in Office XP SP1. And Internet Explorer frame display is disabled in the "restricted sites" zone, which reduces the opportunity for the frames mechanism in HTML email to be used as an attack vector.
SECURE IN DEPLOYMENT: To help customers deploy and maintain our products securely, we have updated and significantly expanded our security tools in the past year. Consumers and small businesses can stay up to date on security patches by using the automatic update feature of Windows Update. Last year, we introduced Software Update Services (SUS) and the Systems Management Server 2.0 SUS Feature Pack to improve patch management for larger enterprises. We released Microsoft Baseline Security Analyzer, which scans for missing security updates, analyzes configurations for poor or weak security settings, and advises users how to fix the issues found. We have also introduced prescriptive documents for Windows 2000 and Exchange to help ensure that customers can configure and deploy these products more securely. In addition, we are working with a number of major customers to implement smart cards as a way of minimizing the weak link associated with passwords. Microsoft itself now requires smart cards for remote access by employees, and over time we expect that most businesses will go to smart card ID systems.
COMMUNICATIONS: To keep customers better informed about security issues, we made several important changes over the past year. Feedback from customers indicated that our security bulletins, though useful to IT professionals, were too detailed for the typical consumer. Customers also told us they wanted more differentiation on security fixes, so they could quickly decide which ones to prioritize. In response, Microsoft worked with industry professionals to develop a new security bulletin severity rating system, and introduced consumer bulletins. We are also developing an email notification system that will enable customers to subscribe to the particular security bulletins they want.
WHAT'S NEXT
In the past decade, computers and networks have become an integral part of business processes and everyday life. In the Digital Decade we're now embarking on, billions of intelligent devices will be connected to the Internet. This fundamental change will bring great opportunities as well as new, constantly evolving security challenges.
While we've accomplished a lot in the past year, there is still more to do - at Microsoft and across our industry. We invested more than $200 million in 2002 improving Windows security, and significantly more on our security work with other products. In the coming year, we will continue to work with customers, government officials and industry partners to deliver more secure products, and to share our findings and knowledge about security. In the meantime, there are three things customers can do to help: 1) stay up to date on patches, 2) use anti-virus software and keep it up to date with the latest signatures, and 3) use firewalls.
There's much more I'd like to share with you about our security initiatives. If you would like to dig deeper, information and links are available at http://www.microsoft.com/mscorp/execmail/2003/01-
Bill Gates
For information about Microsoft's privacy policies, please go to: http://www.microsoft.com/info/privacy.htm
Call (206) 338-5780 COLLECT for information about a genuine BA, BS, MA, MS, MBA, or Ph.D.
Interesting. So you would prefer to let an undocumented state-machine PRNG, seeded in an undocumented way from the TPMs NVRAM and (alledgedly) randomized with additional entropy input generate your keys?
I can only imagine you did not read the TPM specs. Some excerpts:
...
...
'Reporting of Integrity Metrics' of the TPM:
The corresponding public key (of a key pair) is an identity key, since it is a cryptographic value by which the TPM is known.
And here's the argument for using state-machine with appended SHA1 pseudo RNG instead of a true RNG
This architecture is choosen to provide a good source of randomness data without requiring that the TPM include a genuine source of unpredictable data (which may be expensive).
So they've choosen a 'good' random source instead of the 'best possible' random source to (maybe) reduce production costs. IMHO this is misleading information. A P-N junction noise source costs next to nothing.
Draw your conclusions.
Actually, IBM has offered a hardware strong-crypto board for a couple years now. I don't have the price or the specs at hand, but I noticed the drivers for it in the kernel source back when 2.4 came out. I'm pretty sure the military and the banks are using these boards, keeping lives and transactions secure.
C|N>K
USB stick isnt better. Your private key has to be transfered to computers main memory all the time you sign or decrypt something because the key is needed by the encryption/sign algorithm.
This time a trojan horse can steal your private key. This key is useless forever. You have to revoke the key, create a new one and build a new web of trust.
With a TCPA-Chip your private key never leaves the chip (if configured so). An attacker my use your computer to sign/encrypt in you name but never gets the key itself. After you've detected the trojan horse and replaced the compromised programs you are "secure" again.
For the same reason you cant replace a smartcard with a floppy disk or USB stick.
muhh
But the problem is: users will want to get their private keys in order to transfer them to other users and other machines.
When you have music encrypted with your SPECIFIC private key and want to send it to your friend you will have problems.
You will need to send him this SPECIFIC private key so both of you will be able to listen to your encrypted music. Here, the chip comes into play.
Chip will disallow YOU from gaining access to one of YOUR private keys. You will be able to use the key, however not transfer it.
And because the key will be only allowed to be used by a specific signed application, you will not be able to decrypt the music.
And now... you are fucked.
So... what will you do in order to get your private key out of the chip to some other computer?
Or to transfer a specific 'music listening' private key to your friend?
You will not be able to get YOUR private keys from YOUR box. You will have many of private keys or more precisely applications will be able to use them. Not even every application, just a signed one (because application private key will be given out just to application with correct signature)
you can figure it out
you are screwerd
You always have to trust the firmware. Nothing new with TCPA here. What about firmware in disk drives, video cards, network cards, scsi host adapters ...? Did you read the code?
The TCPA-Chips ist not in a better position than the other controllers inside you computer. Parts of your VGA BIOS are executed while booting your computer. The code can do anything. Please remove your graphic card before thinking about privacy issues in TCPA-Hardware.
muhh
Search slashdot, or google more info.
9 5, 3341369,00.html
Like here:
http://www.techtv.com/news/internet/story/0,241
It encrypts your stuff ... doesn't give you the key ... That's tcpa
After reading the whitepapers and all, I'm kind of impressed with TCPA. It's a new capability that really could be used to make a system more secure and stable. Kudos to IBM and the guy for AMI for attempting to explain it.
So the question is how will we use this new capability?
-- $G
- Hardware TCPA is NOT "ok" unless it is possible for anyone to install software that emulates, completely, every function of hardware-TCPA in such a way that it is impossible for any application (e.g. a media player) to know whether the environment is a software emulated-TCPA or a hardware-TCPA.
If there is some way an application can reliably detect it is running on software-emulated-TCPA, then it becomes possible to have a "locked-down" restricted PC, e.g. a PC where certain software cannot be modified to perform new functions. Applications would be able to refuse to run outside of the predetermined hardware-TCPA environment.Why oil price increase equals economic trouble (Score: Interesti
Hahahaha.... At last the Linux community can make Linux so that it can only run our software!! We can cut out all competition and use our monopoly power to.... Oh Wait!!
The race isn't always to the swift... but that's the way to bet!
The keys in TCPA hardware are not "your" keys at all. When you talk about "somebody's keys" you mean their personal keys which they use to identify themselves, e.g., to sign their email, to login, etc.
The keys you are talking about are the keys inside and belonging to the TCPA-enabled PC, settop box, or other electronic device. These keys are used to control functions specific to that particular piece of hardware.
If the keys in TCPA hardware were really "your" keys, you could copy them whenever you like and take them with you to whichever device you happened to be sitting in front of. But you couldn't do that with TCPA because you're not allowed to.
TCPA really means lockdown enabler.
Why oil price increase equals economic trouble (Score: Interesti
The keys in TCPA hardware are not "your" keys at all. When you talk about "somebody's keys" you should mean their personal keys which they use to identify themselves, e.g., to sign their email, to login, etc.
The keys you are talking about are the keys inside and belonging to the TCPA-enabled PC, settop box, or other electronic device. These keys are used to control functions specific to that particular piece of hardware.
If the keys in TCPA hardware were really "your" keys, you could copy them whenever you like and take them with you to whichever device you happened to be sitting in front of. But you couldn't do that with TCPA because you're not allowed to. TCPA means parts of your PC can get locked down permanently.
With TCPA you are no longer free to upgrade your PC when you like, how you like. You lose your existing privileges.
TCPA really means lockdown enabler.
Why oil price increase equals economic trouble (Score: Interesti
The real irony is that proponents of TCPA are mis-describing the private keys in TCPA hardware as "your" keys. Yet, despite what they say, it turns out the keys in TCPA hardware are not "your" keys at all. When you talk about "somebody's keys" you should mean their personal keys which they use to identify themselves, e.g., to sign their email, to login, etc.
The keys TCPA proponents are talking about are the keys inside and belonging to the TCPA-enabled PC, settop box, or other electronic device. These keys are used to control functions specific to that particular piece of hardware.
If the keys in TCPA hardware were really "your" keys, you could copy them whenever you like and take them with you to whichever device you happened to be sitting in front of. But you couldn't do that with TCPA because you're not allowed to. TCPA means parts of your PC can get locked down absolutely and permanently.
With TCPA you are no longer free to upgrade your PC when you like, how you like. You lose your existing privileges.
In a nutshell TCPA really does mean lockdown-enabler.
Why oil price increase equals economic trouble (Score: Interesti
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 means LOCK-down, LOCK-out, LOCK-up enabler. Avoid getting anything with TCPA.
Why oil price increase equals economic trouble (Score: Interesti
Would that also mean identity theft?
No, TCPA is not "good thing" unless you like having hardware you cannot fully use.
If you read the white papers and the counter-rebuttal you may not see the most important point about TCPA: TCPA means you're not allowed to copy the keys inside your own PC!
The real irony is that proponents of TCPA are mis-describing the private keys in TCPA hardware as "your" keys. Yet, despite what they say, it turns out the keys in TCPA hardware are not "your" keys at all. When you talk about "somebody's keys" you should mean their personal keys which they use to identify themselves, e.g., to sign their email, to login, etc.
The keys TCPA proponents are talking about are the keys inside and belonging to the TCPA-enabled PC, settop box, or other electronic device. These keys are used to control functions specific to that particular piece of hardware. This is a lock-down enabling restriction on what you can and cannot do with your PCs, electronic equipment, etc.
If the keys in TCPA hardware were really "your" keys, you could copy them whenever you like and take them with you to whichever device you happened to be sitting in front of. But you couldn't do that with TCPA because you're not allowed to. TCPA means parts of your PC can get locked down absolutely and permanently.
In a nutshell TCPA really does mean lockdown-enabler. Avoid getting anything with TCPA.
Why oil price increase equals economic trouble (Score: Interesti
I'll believe it when I see it implemented. The strangest thing I have ever noticed is the corperate world and the underground drug world have many things in common as far as interaction goes. How do deal with both can be summerized as, "your not paranoid, everyone(in the industry) is, or might be out to get you at one point in time. Believe it when you see it, pay nothing till you do. When you try it, make sure you are with as many people who have as much to loose as you as they have people working for them."
I think you misunderstand microsofts relationship to IBM. IBM HATES microsoft with a passion. Why else would they spend millions upon millions of dollars on a competing OS. They are still sore from that shitty deal they got from MS with DOS in the 80s, they are even MORE sore about OS/2(which was partially developed by MS)
IBM has bashed MS publicly on many occations, and there is no reason for IBM to co-operate with them, especially after investing in red hat so seriously.
I would not say "WOW IBM IS TEH RIGHT" just yet, we still gotta see what REALLY happens. Just as long as the end user is given the key at the end, it would work well, if not, its gonna suck. But in any case, it should be a removable chip, just incase someone buying "used" hardware doesn't get screwed.
If I remove my video card, Netscape v2's SSL will still be insecure. Your "solution" does not solve poor algorithms for generating private keys. I have not yet run into any disk drives, video cards or SCSI host adapters that claim to be part of providing an encryption solution. I have run into two different types of network cards that claim to be part of an encryption solution, IPSec Accelrators and 802.11 cards with WEP. With every network card that does IPSec in hardware I have run into, I get to choose the algorithm that generates the encryption key so I don't have to trust a prioritary seed generator. And in terms of WEP, well... I guess WEP just goes to show why we can't trust hardware/firmware that claims to be part of a security solution. Would you recommend that I take my video card, which does not claim to be a security device at all, out of my system to fix WEP?
The TCPA is a method that would due well to get the backing of security groups. ATI and Nvidea aren't trying to get any security groups to claim that their products improve security. In fact, we have already informed them what we think about their products broadcast everything they display for a tempist attack. But while IBM seems to be "laying it all out" by promoting TCPA as an open standard with their solution useable with GPL drivers, they leave out access to a critical component that has a history of being flawed--anotherwords the source of entropy for generating the key. Since the firmware generates the key and does not accept a key from an external source, the only way to audit the strength of the key produced is to audit the firmware itself. IBM still has not made that available. Without that, I submit that the usefulness of the GPL driver for IBM TCPA is compariable with the usefulness for a GPL driver to a 802.11 card with WEP. There are other known attacks for encryption devices that we could help address with the source to the firmware but not with the source to the driver.
Wow! Anybody that doesn't unreservedly believe that the worlds largest corporations will continually stand up for consumer and personal rights really IS a nut!
p.s. I believe it's "The Archies" that control the whole world. I mean,you've got to have OLD SCHOOL connections to control the world.
"Spatula city, we sell spatulas....and thats all!" -Spatula City commercial jingle, UHF (that movie rocks)
If they can provide public key encrypted media for once, I would applaud the content distributors for FINALLY catching on. However, just remember, you can always extract the decoded media once you know the chip has verified said encoded media. It will at some point grace your RAM decoded, where you can pick it up again because you are CLEVER and not using a Windows product.
No. You're wrong. And you posted the same canned response elsewhere, which is kind of silly.
:)
:)
The TCPA keys are your keys. The TCPA crypto processor generates each (public, private) key pair at your command, and keeps the private key locked inside it's innards for you and gives you the public key to do stuff with.
Did you read the article? You can do whatever you damn well please with them! The IBM guys suggested using them as ssh keys and stuff like that. Or a means to encrypt data that a (non-privileged) intruder who breaks in over the 'Net won't be able to crack.
Of course, the down side to this is that you can't recover the data without the keys inside the original crypto processor, so if your motherboard is fried in a power surge or something, you're in pretty deep sh*t. But hopefully that won't happen
A far as all the TCPA/Palladium/DRM nonsense goes, the functionality of TCPA is nothing more or less than a simple daughtercard that enables hardware cryptography. Trying to write strict provisions to lock down a system into requiring a particular bootloader, OS and secure driver to authenticate the system to restrict permissions on what the user can do with their data is a fool's errand, and if Microsoft IS stupid enough to try, well then I wish them well, because it'll be fun to watch them fail spectacularly
No, you don't always have to trust the firmware. Take a look at the LinuxBIOS project. You can also pressure makers of video cards, network adapters, and other hardware, to open up their firmware.
Open source drivers are nice, but they aren't much of a concession. These days, drivers don't do much more than act as an abstraction layer for the operating system to communicate with the firmware on the hardware. There aren't any nuts-and-bolts of substance to look at in device driver code, just translation. And the card manufacturers know that.
Open source drivers are nice, but they aren't much of a concession. These days, drivers don't do much more than act as an abstraction layer for the operating system to communicate with the firmware on the hardware. There aren't any nuts-and-bolts of substance to look at in device driver code, just translation. And the card manufacturers know that.
Also, as one reader also pointed out: since the firmware is closed, there's no way for the user to know how it's gathering the entropy to generate the keys with. So there's no way to know how secure your key really is. You just have to take the vendor's word for it. But you can trust the vendor, right? Um, right...?
I doubt that most people who will read those documents online will spend the time, trouble, paper, and ink to print it out just to read it. For the few people that need to print it out, printing HTML would probably work well enough. Page numbers aren't that important if the document is structured well in, say, outline format. PDF is very poor for viewing content on computer screens. That's a fact. Forcing page breaks onto viewing screens is just senseless. Even a simple PDF-HTML conversion like Google does would make it easier to read on a screen.
"Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."
...can be found here: http://www.notcpa.org we've also installed a wiki. http://wiki.notcpa.org go, spread the word!
I don't know what agenda you have but you are not discussing TCPA logically or fairly.
In common English, if something is said to be yours it is implied you have a degree of control over the object itself. The private keys in hardware TCPA are not allowed to be copied by anyone, even the owner of the hardware. It doesn't matter who or what originally created the public/private key pairs in TCPA hardware. The simple fact is nobody can copy the private keys, even if you desperately want to copy them for valid reasons, for example, when you want to copy the private keys to your new computer so as to be able to continue to enjoy your music/video collections which you purchased for your old computer.
If I cannot copy "my" private keys wherever I "damn well please", to borrow your cute little phrase, then they are not "my" private keys at all. Call a spade, a spade: The private keys belong to the TCPA hardware; they are not my keys unless I can copy them wherever and whenever I want.
I get all the computational capability I need from the CPU. What does TCPA have to offer? Oh yes, a miserly Scrooge-like hardware encryption scheme which disallows me from copying the private keys and is ideal for implementing lock-out, lock-down, lock-up restrictions I don't want on my properly purchased data and hardware.
The supposed "advantage" of the private keys in TCPA hardware not being copyable is a disadvantage. If your system is vulnerable to intruders, fix your system -- then nobody without authority can copy your private keys. TCPA denies me the choice of copying my private keys.
Forget hardware TCPA. Put the effort into designing secure software systems that intruders cannot break into. For a secure software system, nobody can copy your private keys except you unless you allow someone else to do so (your partner?). This means you, not the hardware, gets to choose how to manage your private keys. That flexibility is useful. Give people the freedom to choose the software they prefer. Don't force the same hardware TCPA onto everyone's motherboard where it might stand a chance of becoming Scrooge's toolbox for content suppliers. When suppliers start locking the things you buy to a particular public/private key pair on a particular TCPA-CPU/device, people are going to regret having bought anything with TCPA.
Avoid getting anything with TCPA.
Why oil price increase equals economic trouble (Score: Interesti
Nonsense. The network is the bottle neck given modern and fast computers.
... I consider it an essential feature to be able to copy out (securely) any and all keys the chip has generated ...
Can you back up that requirement with an application and the threat modes the application is being protected against? Chances are, most applications that allow the key to be exported don't need the level of security provided by the chip in the first place.
The ability to stop keys from being exported is often a vital feature of hardware crypto systems. For example that is why the Microsoft CAPI interface (at least in versions up to a couple of years ago) is almost useless as a library interface to hardware crypto engines -- it allows all keys to be exported.
To further explain the dangers of key exportation, CAPI only allows these keys to be exported when they are encrypted with an asymmetric key. You might think this meets the "securely" part, but in reality is very simple to compromise. Just create your own "known" asymmetric key, and export all the keys under it. Now you can easily decrypt and read the supposedly protected keys.
A former employer of mine made the first actual hardware CAPI driver (and the second driver created - NT 4.0 days). We dealt with the problem in two ways - the most obvious was to create a secure out-of-channel method for disabling the key export command. The second was more subtle, and more typical of secure hardware design, was to provide a method of limiting the introduction of keys into a system.
The other alternative to key export is the method used by IBM in this case, which is not to allow the key to be exported at all. This is also popular with a number of smartchip/card designs. These keys are typically only used for signing, because real life systems usually need an export function for encryption keys. I've always felt there were ways that you could securely export a signing key (warning! many people don't agree with this statement, at least not at until I spend 10 minutes explaining how and why). But I can agree that in simple designs, disallowing the exportation of signing keys is generally a good thing.
Despite working in the industry, I am generally against DRM (see my post history). I'm writing this because I'm tired of seeing basic hardware crypto security mechanisms described as useful for DRM only. Lets face it, these are tools, and they can be used for good or bad!