A little further down in this thread, I wrote the following...
Boy thems stoopid trusted computin foaks shore is ignert. They must haves never thunk of emulation.
You wrote... The OS is talking to emulated hardware, so you can generate whatever response is needed.
The whole point is that YOU CAN NOT generate the needed response. The TPM's private key is a secret. See the rest of this thread. Your emulated TPM doesn't have a secret key whose counterpart public key was signed. The TPM is not going to give you, or anyone, its secret key. The TPM will sign something, but only if you can provide a certificate that you are trusted. You can only get this from the OS. The certificate can be inspected, just like happens on the web. I can see that the OS signed your certificate saying you are trusted, but can I trust the OS. Well, that certificate has embedded within it, a certificate from the boot loader that certifies that the OS is trusted. That certificate has an embedded certificate from the BIOS/motherboard saying that the boot loader is trusted. And that certificate has one saying that the hardware trusts the BIOS. The hardware trusts the BIOS because it was signed by someone that the TPM can trust (like Pheonix, etc.). I know that a trusted (not emulated) TPM signed it, because the TPM has a certificate that, lets suppose, Dell has signed saying that the TPM's public key is genuine. (Nobody has ever known, nor ever will know the TPM's secret key.)
So unless you are already in the chain of trust, YOU CAN NOT generate the needed response. Unless you have a certificate with embedded chain of certificates that you can present to the TPM, it isn't going to sign anything for you. Therefore, your plug-in cannot "prove" to the RIAA that it is okay to send me that media stream. And horrors(!), someone not in the room with you right now, not crouched around the monitor right now, might lay eyes on the video or hear the audio.
The motherboard must first examine the bootloader to see that it trusts it. If so, then trust is passed to the (un-compromised) boot loader.
The boot loader can look at the OS it is loading to see if it is trusted. If so, then trust can be given to the OS. An untrusted OS could be loaded, but it would have no trust. The untrusted OS can't ask the TPM chip "Hey, sign this for me using your secret private key."
If the OS is trusted, it can then determine if certian applications are trusted. QEMU would not be trusted. It could run, but would not be trusted.
When you run RIAA-Approved software, it is able to prove, via. a chain of trust (certificates) that it is trusted and running on a non-compromised system.
So why can't QEMU emulate the TPM chip? Because it does not know any secret keys. Each TPM has a secret key. And that key is a secret. Forever sealed in the chip. Even the manufacturer does not know the key. The key is a true secret. Nothing outside of the TPM chip itself has ever seen that private key. The TPM's public key was signed at the factory. You and everyone can know the public key of any TPM. And those public keys can be proven authentic because of their certificates (i.e. they are signed). You could generate an emulated TPM public/private key, but the public key is not signed by Dell. You know the public key of your box, but not the secret private key, which you can probably never know.
The highest Office that I have installed (and which I generally ignore) is Office XP.
I have not used nor read the eula for Office 2003. I'll take your word for it, since I have no reason to doubt. It is nice to see that Office 2003 would allow you to run it on any platform. This is new information to me.
You can see why I reacted to your very general statement "The license for any non-OS product from Microsoft says nothing about having to run it on Windows.", since it is demonstrably false.
Um wrong. I have plenty of computers (at home). I have never purchased a single Microsoft operating system. Ever. I do not run any MS Operating systems (at home).
(Being Slashdot, I suppose I must add: I also do not run any copies of any MS OS, pirated or otherwise. At work, I use genuine legal MS OSes and other products.)
The license for any non-OS product from Microsoft says nothing about having to run it on Windows. They assume you will, but WINE breaks that assumption.
Very wrong.
Microsoft Visual FoxPro 8 EULA says....
....you agree: (i) except as otherwise noted in Section 2.1 (Sample Code), to distribute the Redistributables only in object code form and in conjunction with and as a part of a software application product developed by you that adds significant and primary functionality to the Redistributables ("Licensee Software"); (ii) that the Redistributables only operate in conjunction with Microsoft Windows platforms;
Short version: A Microsoft development tool expressly requires your software products can only be run on Microsoft Windows.
Do you really believe that MS Office or any other MS applications' EULA's try to tie you in to Windows?
We're talking about the software company whose FrontPage 2000 product EULA says that you can not produce web pages that make disparaging remarks about Microsoft, Expedia, etc., etc., etc. (Thus, if say, CNN uses FrontPage 2000, I guess I can assume that anything they say about Microsoft is unbiased.)
Are you just talking out of your posterior? Or have you actually ever read a single MS EULA?
This could be a great thing for advertisers imagine being able to have a buy it now logo pop up during your comercial. But I guess if you are watching on a Tivo you wouldn't see the commercial.
Now imagine the possibilities of having a buy it now logo pop up during the program content!
Do you want to buy the sofa that Jane is sitting on? It looks comfortable. You've never seen an episode where Jane's sofa was not sparkling clean.
Do you want to buy the cell phone that Sam is using? It has exellent coverage. You've never seen an episode where he had no signal.
Advertisers will love this. It could be the thing to make Tivo some money.
No doubt this would be what Tivo execs will want.
Too bad the very user base who wants a Tivo would abandon Tivo in droves.
I don't think that current technology makes it practical. Unfortunantly, we need at least one more generation of hardware improvements before the universal multi-purpose brian implant can become a reality.
Not only is GPS tracking needed, but also real time transmit-receive capability. It is not possible to put the entire database of copyright works into your implant. Therefore, when you see or hear something, your implant can communicate with a central RIAA/MPAA database in real time, determine who owns the copyright, and then appropriately charge your credit card for what you have just seen or heard.
It is even less technically feasible, at present, to determine whether you are thinking subversive thoughts which lie outside the scope of consuming content or doing productive work for your employer.
Also somewhat infeasible is for the implant to determine or be remotely directed that it is necessary to administer needed medications into your system. (Need being determine by the implant firmware, or by remote command.)
Improvements in processing power will be needed for various a/v decoders if we wish to convert all content to be DRM encoded almost all the way to the brain.
I'm sure others here can think of other current technical limitations that mean we will have to be patient and wait for the next generation of brain implant toys.
Even further out, more sci-fi, would be not only to monitor thoughts, but also to interact with thoughts. Your implent could make it possible for people of the right social standing to be able to have virtual conferences. For mere workers, it would be possible to put up virtual walls that one would be unable to walk through.
Think of the applications and imagine the tremendous benefits. Think of how much safer this wonderful technology could keep all of us. It would protect our corporations from the scourge of piracy. It would save all of us from the unpleasantness of people who express dissenting views.
Oracle and friends can make the following convincing argument to PHB's....
....but PostgreSQL is still going to charge you twice as much to run PostgreSQL on a dual core CPU as you would pay to run PostgreSQL on a single core CPU.
you're ignoring that the RIAA has the money and legal power to induce the hardware vendor to record those numbers before shipment, so they can retroactively revote your applications' security under a court order.
You're missing that the hardware vendor cannot possibly know what the TPM's PRIVATE key is. Even the chip foundary that made the TPM chip does not (and cannot) know the TPM's secret PRIVATE key.
can you really think of any scenario where the admin of an RIAA computer (by which I really mean a computer owned by a corporate music store) would willingly decide to execute any program that didn't come from the OS vendor,
My hypothetical P2P app does not come from the OS vendor. I don't really care if the RIAA runs my P2P app or not. If they do, I know that my P2P app won't run unless it can trust the RIAA's OS, bloat loader, BIOS and hardware.
My point is that the RIAA cannot create their own P2P app that connects to my P2P network, as they do today. My (hypothetical) P2P app would only interconnect with other apps that can prove that they are also trusted.
The PC Makers will probably already keep a list of the PUBLIC keys of the TPM.
Anybody who wants my TPM's public key can have it. I'll put it in my slashdot sig.
Nobody or nothing ever has or ever can know the PRIVATE key inside the TPM. It is a secret. Even the chip foundary that made the TPM chip cannot possibly know what the private key is that is inside the TPM.
I can sign my own app with my own public/private keys.
My app can then follow the chain of trust. My app asks the OS for a checksum of the app. My app asks the OS to provide proof that the OS is not tampered with. The OS asks the bloat loader to prove that it is uncompromised and that it approves of the OS. The bloat loader asks the BIOS to prove that it is trusted and that it approved of the bloat loader. The BIOS can get proof from the TPM that the BIOS is uncompromised.
Now I have proof from the TPM, which I can trust, that the BIOS is okay.
I have proof from the BIOS that the bloat loader is okay.
I have proof from the bloat loader that the OS is trusted.
I have proof from the OS that it trusts that my app is the one that I, that is ME, MYSELF, that I signed.
Now my app could be designed to only connect to something that can prove that it is also signed by me.
Maybe my app is just the core of a P2P. The plumbing. Maybe it has loadable search, play, UI etc. modules. You can customize the UI. Use different widget sets (GNOME, KDE, etc.). Add new wizbang features. But you can't control the underlying plumbing of the P2P network. It is trusted.
End result: trusted p2p plumbing. Customizable features on top. But from a plug in module, you can't tell where a file came from or where it is going to. Using swarming routing like MUTE makes it unlikely that even traffic analysis of TCP/IP will tell you anything.
My new Dell Trusted WizBang 9000 has a TPM chip. The TPM has a PUBLIC and a PRIVATE key.
Dell has issued a certificate saying that the TPM's PUBLIC key is genuine. Now as long as I can trust that VeriSlime signed Dell's certificate, and VeriSlime's signature says that Dell is authorized to then issue these TPM certificates, and then I can verify that Dell's certificate for my TPM public key is correct, I can know that the TPM module in my computer is genuine. (Not some "emulated" TPM running in a Virtual PC.)
The RIAA can twist Dell's arm into signing something, but that does not matter.
The PRIVATE key of my TPM is a secret inside the TPM itself. No human ever has or ever will know the PRIVATE key inside the TPM. Not only a human, but nothing outside of the TPM has ever kwown my TPM's private key. The TPM seecretly generated it at manufacture tiime. That is what makes the private key inside the TPM such a secret. The TPM is designed to take the private key with it to the grave if you make any attempt to try to recover the secret out of the TPM chip.
The TPM can now sign something. Anyone who wants it has the public key to my TPM. In fact, my TPM willingly gives out its PUBLIC key. Because Dell has signed my TPM's public key, anyone who cares can verify that anything my TPM chip signs is trusted. (NOTE: No internet connection is necessary to verify trust!)
Once you understand how this works, you can see that anyone can trust their application on the RIAA's computer, just as much as the RIAA can trust their code on my computer.
TPM is a mechanism to make sure that I can be assured that the RIAA has not compromised my application.
Internet access is not a necessary component. Even with no internet access, here is why an emulated TPM cannot work.
Dell issues a certificate (stored in your TPM) that says that your TPM's private key is certified by Dell.
You can't fake this certificate anymore than you can fake someone's web certificate for SSL so that your server can reliably claim to be, say, Microsoft.
Your emulator can have an "emulated" TPM with a private key and public key. But you can't get Dell (or any other manufacturer) to sign your emulated TPM public key.
Now you could make your emulated TPM use the same public/private key pair as your actual hardware uses. Dell has signed your hardware's public key. But you can't get the private key out of the dang chip. In fact, niether could Dell nor anyone else either! That is why the private key in your TPM is a true secret. No human ever has known or ever will know the private key that is inside your TPM chip. In fact, nothing outside of the TPM has or ever will know the secret. The TPM may even destroy the secret if you try to get at it. All you've got is the TPM's public key, and a certificate from Dell saying it is a genuine TPM public key.
Anyone who trusts, say, VeriSlime to have issued Dell a certificate, and then who also trusts that Dell would ONLY sign a genuine TPM public key, can then trust that anything that the TPM has signed was in fact signed by a genuine TPM -- not an emulated one.
Without any Internet access at all, just knowing a few root certificate issuers such as VeriSlime, I can verify that your system is trusted. Just inspect the certificate from Dell to make sure Dell signed the TPM pub key, and that Dell's public key is signed by VeriSlime. I can now trust anything that the TPM signs.
The RIAA / MPAA wants to be able to "trust" that I have not tampered with their application, or substituted my own application.
Similarly, I want to be sure that I can "trust" that the RIAA / MPAA has not tampered with my, nor substituted their own P2P application.
Imagine a GPL "trusted" P2P application. You can see the source. You can compile it on a UN-trusted GCC compiler -- but only with very specific compiler options such that it produces the exact trusted binary I have certified.
The P2P app will only connect with a trusted copy of the same application. I can "trust" with the same level of trust that other copies of my P2P app are genuine non-RIAA tampered copies.
(This leaves unaswered the issue of traffic analysis. The IP addresses of the nodes that you end up connecting to. But then, this could be addressed by a swarming-routing protocol like MUTE uses.)
Here's a different argument....
Just like the bad guys can trust my computer against me to ensure closedness (i.e. can't copy / print / save an e-mail), I can similarly trust the bad guys' computers to ensure openness. For instance, I can be assured that my open source can only be processed or manipulated using tools that I trust to keep it open.
My point is that the trust can be used to our benefit. We can "trust" the bad-guys' computers to do our will.
And how exactly is this useful to the user? Why would I want to run an application that has its own private storage which can't be accessed by other applications or the OS?
I might want only a limited set of applications accessing a certian storage area.
P2P application
XMMS
Then in a different secured storage area, I only want a limited set of applications accessing....
Usenet downloader
Pr0n Viewer
Since I can trust the software within each group, I know that no evil RIAA people will be accessing my sacred secured storage. (Of course, torture may be allowed in the US -- after all -- think of all the poor record executives.)
Imagine a trusted P2P application that will only interconnect with the same trusted application? The trust works both ways. Just like the RIAA thinks they can "trust" their software running my computer to not be of my own creation, or a tampered version of their software, I can "trust" that MY software running on the RIAA's computer is similarly my original code, not tampered with or substituted.
Knowing Microsoft it will probably have some security hole that will infect my tv with spyware.
Not until your TV has a cell processor.
Probably not spyware. More likely adware. Each adware will be a "software cell" that runs on a single APU of a cell processor. Because of the way a cell processor works the (software) cells will be able to migrate to other cell processors, such as your PlayStation 3, or other consumer electronics devices.
Slashdot Mirror
A little further down in this thread, I wrote the following...
Boy thems stoopid trusted computin foaks shore is ignert. They must haves never thunk of emulation.
You wrote...
The OS is talking to emulated hardware, so you can generate whatever response is needed.
The whole point is that YOU CAN NOT generate the needed response. The TPM's private key is a secret. See the rest of this thread. Your emulated TPM doesn't have a secret key whose counterpart public key was signed. The TPM is not going to give you, or anyone, its secret key. The TPM will sign something, but only if you can provide a certificate that you are trusted. You can only get this from the OS. The certificate can be inspected, just like happens on the web. I can see that the OS signed your certificate saying you are trusted, but can I trust the OS. Well, that certificate has embedded within it, a certificate from the boot loader that certifies that the OS is trusted. That certificate has an embedded certificate from the BIOS/motherboard saying that the boot loader is trusted. And that certificate has one saying that the hardware trusts the BIOS. The hardware trusts the BIOS because it was signed by someone that the TPM can trust (like Pheonix, etc.). I know that a trusted (not emulated) TPM signed it, because the TPM has a certificate that, lets suppose, Dell has signed saying that the TPM's public key is genuine. (Nobody has ever known, nor ever will know the TPM's secret key.)
So unless you are already in the chain of trust, YOU CAN NOT generate the needed response. Unless you have a certificate with embedded chain of certificates that you can present to the TPM, it isn't going to sign anything for you. Therefore, your plug-in cannot "prove" to the RIAA that it is okay to send me that media stream. And horrors(!), someone not in the room with you right now, not crouched around the monitor right now, might lay eyes on the video or hear the audio.
>> Putting lots of people in the Dalles makes sense. Putting lots of computer doesn't.
> It's good to know what we value most.
People can get out of the way of danger. Computers in a data center can't.
Hey, ssh, quiet down, they're "searching".
Don't you mean Googling?
From what I hear, the term "Googling" is now the word that means "searching".
You betcha!
Boy thems stoopid trusted computin foaks shore is ignert. They must haves never thunk of emulation.
NO. Not if the hardware has "trusted computing".
The trust begins at the hardware.
The motherboard must first examine the bootloader to see that it trusts it. If so, then trust is passed to the (un-compromised) boot loader.
The boot loader can look at the OS it is loading to see if it is trusted. If so, then trust can be given to the OS. An untrusted OS could be loaded, but it would have no trust. The untrusted OS can't ask the TPM chip "Hey, sign this for me using your secret private key."
If the OS is trusted, it can then determine if certian applications are trusted. QEMU would not be trusted. It could run, but would not be trusted.
When you run RIAA-Approved software, it is able to prove, via. a chain of trust (certificates) that it is trusted and running on a non-compromised system.
So why can't QEMU emulate the TPM chip? Because it does not know any secret keys. Each TPM has a secret key. And that key is a secret. Forever sealed in the chip. Even the manufacturer does not know the key. The key is a true secret. Nothing outside of the TPM chip itself has ever seen that private key. The TPM's public key was signed at the factory. You and everyone can know the public key of any TPM. And those public keys can be proven authentic because of their certificates (i.e. they are signed). You could generate an emulated TPM public/private key, but the public key is not signed by Dell. You know the public key of your box, but not the secret private key, which you can probably never know.
The highest Office that I have installed (and which I generally ignore) is Office XP.
I have not used nor read the eula for Office 2003. I'll take your word for it, since I have no reason to doubt. It is nice to see that Office 2003 would allow you to run it on any platform. This is new information to me.
You can see why I reacted to your very general statement "The license for any non-OS product from Microsoft says nothing about having to run it on Windows.", since it is demonstrably false.
The redistributables, if you look at the list, includes the VFP runtime.
Without the VFP runtime, I can build a ".app", but not a ".exe".
Unless you have a copy of VFP, there is no sense in me sending you a ".app" file.
If I build a "setup.exe" for you, It probably should be installing the VFP runtime dll's and a ".exe" file.
Hence, you cannot develop an application that is intended to run on a non-Windows OS.
Way after. VFP 8 was released, IIRC, late 2003.
Um wrong. I have plenty of computers (at home). I have never purchased a single Microsoft operating system. Ever. I do not run any MS Operating systems (at home).
(Being Slashdot, I suppose I must add: I also do not run any copies of any MS OS, pirated or otherwise. At work, I use genuine legal MS OSes and other products.)
The license for any non-OS product from Microsoft says nothing about having to run it on Windows. They assume you will, but WINE breaks that assumption.
....you agree: (i) except as otherwise noted in Section 2.1 (Sample Code), to distribute the Redistributables only in object code form and in conjunction with and as a part of a software application product developed by you that adds significant and primary functionality to the Redistributables ("Licensee Software"); (ii) that the Redistributables only operate in conjunction with Microsoft Windows platforms;
Very wrong.
Microsoft Visual FoxPro 8 EULA says....
Short version: A Microsoft development tool expressly requires your software products can only be run on Microsoft Windows.
Do you really believe that MS Office or any other MS applications' EULA's try to tie you in to Windows?
We're talking about the software company whose FrontPage 2000 product EULA says that you can not produce web pages that make disparaging remarks about Microsoft, Expedia, etc., etc., etc. (Thus, if say, CNN uses FrontPage 2000, I guess I can assume that anything they say about Microsoft is unbiased.)
Are you just talking out of your posterior? Or have you actually ever read a single MS EULA?
It is not clear at all that SCO even owns any rights to sell.
Sun payed for FUD, pure and simple.
Sun's payment to SCO was to finance FUD about Linux.
SCO does not own copyrights on any code that appears in Sun's OS. Sun would surely have known this.
Now imagine the possibilities of having a buy it now logo pop up during the program content!
Advertisers will love this. It could be the thing to make Tivo some money.
No doubt this would be what Tivo execs will want.
Too bad the very user base who wants a Tivo would abandon Tivo in droves.
I don't think that current technology makes it practical. Unfortunantly, we need at least one more generation of hardware improvements before the universal multi-purpose brian implant can become a reality.
Not only is GPS tracking needed, but also real time transmit-receive capability. It is not possible to put the entire database of copyright works into your implant. Therefore, when you see or hear something, your implant can communicate with a central RIAA/MPAA database in real time, determine who owns the copyright, and then appropriately charge your credit card for what you have just seen or heard.
It is even less technically feasible, at present, to determine whether you are thinking subversive thoughts which lie outside the scope of consuming content or doing productive work for your employer.
Also somewhat infeasible is for the implant to determine or be remotely directed that it is necessary to administer needed medications into your system. (Need being determine by the implant firmware, or by remote command.)
Improvements in processing power will be needed for various a/v decoders if we wish to convert all content to be DRM encoded almost all the way to the brain.
I'm sure others here can think of other current technical limitations that mean we will have to be patient and wait for the next generation of brain implant toys.
Even further out, more sci-fi, would be not only to monitor thoughts, but also to interact with thoughts. Your implent could make it possible for people of the right social standing to be able to have virtual conferences. For mere workers, it would be possible to put up virtual walls that one would be unable to walk through.
Think of the applications and imagine the tremendous benefits. Think of how much safer this wonderful technology could keep all of us. It would protect our corporations from the scourge of piracy. It would save all of us from the unpleasantness of people who express dissenting views.
PostgreSQL is coming along nicely...
....but PostgreSQL is still going to charge you twice as much to run PostgreSQL on a dual core CPU as you would pay to run PostgreSQL on a single core CPU.
Oracle and friends can make the following convincing argument to PHB's....
you're ignoring that the RIAA has the money and legal power to induce the hardware vendor to record those numbers before shipment, so they can retroactively revote your applications' security under a court order.
You're missing that the hardware vendor cannot possibly know what the TPM's PRIVATE key is. Even the chip foundary that made the TPM chip does not (and cannot) know the TPM's secret PRIVATE key.
can you really think of any scenario where the admin of an RIAA computer (by which I really mean a computer owned by a corporate music store) would willingly decide to execute any program that didn't come from the OS vendor,
My hypothetical P2P app does not come from the OS vendor. I don't really care if the RIAA runs my P2P app or not. If they do, I know that my P2P app won't run unless it can trust the RIAA's OS, bloat loader, BIOS and hardware.
My point is that the RIAA cannot create their own P2P app that connects to my P2P network, as they do today. My (hypothetical) P2P app would only interconnect with other apps that can prove that they are also trusted.
The PC Makers will probably already keep a list of the PUBLIC keys of the TPM.
Anybody who wants my TPM's public key can have it. I'll put it in my slashdot sig.
Nobody or nothing ever has or ever can know the PRIVATE key inside the TPM. It is a secret. Even the chip foundary that made the TPM chip cannot possibly know what the private key is that is inside the TPM.
This is an important concept to understand.
I can sign my own app with my own public/private keys.
My app can then follow the chain of trust. My app asks the OS for a checksum of the app. My app asks the OS to provide proof that the OS is not tampered with. The OS asks the bloat loader to prove that it is uncompromised and that it approves of the OS. The bloat loader asks the BIOS to prove that it is trusted and that it approved of the bloat loader. The BIOS can get proof from the TPM that the BIOS is uncompromised.
Now I have proof from the TPM, which I can trust, that the BIOS is okay.
I have proof from the BIOS that the bloat loader is okay.
I have proof from the bloat loader that the OS is trusted.
I have proof from the OS that it trusts that my app is the one that I, that is ME, MYSELF, that I signed.
Now my app could be designed to only connect to something that can prove that it is also signed by me.
Maybe my app is just the core of a P2P. The plumbing. Maybe it has loadable search, play, UI etc. modules. You can customize the UI. Use different widget sets (GNOME, KDE, etc.). Add new wizbang features. But you can't control the underlying plumbing of the P2P network. It is trusted.
End result: trusted p2p plumbing. Customizable features on top. But from a plug in module, you can't tell where a file came from or where it is going to. Using swarming routing like MUTE makes it unlikely that even traffic analysis of TCP/IP will tell you anything.
You do not understand how this works.
The RIAA's money and power are irrelevant.
My new Dell Trusted WizBang 9000 has a TPM chip. The TPM has a PUBLIC and a PRIVATE key.
Dell has issued a certificate saying that the TPM's PUBLIC key is genuine. Now as long as I can trust that VeriSlime signed Dell's certificate, and VeriSlime's signature says that Dell is authorized to then issue these TPM certificates, and then I can verify that Dell's certificate for my TPM public key is correct, I can know that the TPM module in my computer is genuine. (Not some "emulated" TPM running in a Virtual PC.)
The RIAA can twist Dell's arm into signing something, but that does not matter.
The PRIVATE key of my TPM is a secret inside the TPM itself. No human ever has or ever will know the PRIVATE key inside the TPM. Not only a human, but nothing outside of the TPM has ever kwown my TPM's private key. The TPM seecretly generated it at manufacture tiime. That is what makes the private key inside the TPM such a secret. The TPM is designed to take the private key with it to the grave if you make any attempt to try to recover the secret out of the TPM chip.
The TPM can now sign something. Anyone who wants it has the public key to my TPM. In fact, my TPM willingly gives out its PUBLIC key. Because Dell has signed my TPM's public key, anyone who cares can verify that anything my TPM chip signs is trusted. (NOTE: No internet connection is necessary to verify trust!)
Once you understand how this works, you can see that anyone can trust their application on the RIAA's computer, just as much as the RIAA can trust their code on my computer.
TPM is a mechanism to make sure that I can be assured that the RIAA has not compromised my application.
Internet access is not a necessary component. Even with no internet access, here is why an emulated TPM cannot work.
Dell issues a certificate (stored in your TPM) that says that your TPM's private key is certified by Dell.
You can't fake this certificate anymore than you can fake someone's web certificate for SSL so that your server can reliably claim to be, say, Microsoft.
Your emulator can have an "emulated" TPM with a private key and public key. But you can't get Dell (or any other manufacturer) to sign your emulated TPM public key.
Now you could make your emulated TPM use the same public/private key pair as your actual hardware uses. Dell has signed your hardware's public key. But you can't get the private key out of the dang chip. In fact, niether could Dell nor anyone else either! That is why the private key in your TPM is a true secret. No human ever has known or ever will know the private key that is inside your TPM chip. In fact, nothing outside of the TPM has or ever will know the secret. The TPM may even destroy the secret if you try to get at it. All you've got is the TPM's public key, and a certificate from Dell saying it is a genuine TPM public key.
Anyone who trusts, say, VeriSlime to have issued Dell a certificate, and then who also trusts that Dell would ONLY sign a genuine TPM public key, can then trust that anything that the TPM has signed was in fact signed by a genuine TPM -- not an emulated one.
Without any Internet access at all, just knowing a few root certificate issuers such as VeriSlime, I can verify that your system is trusted. Just inspect the certificate from Dell to make sure Dell signed the TPM pub key, and that Dell's public key is signed by VeriSlime. I can now trust anything that the TPM signs.
Yes we really need it.
The trust works both ways.
The RIAA / MPAA wants to be able to "trust" that I have not tampered with their application, or substituted my own application.
Similarly, I want to be sure that I can "trust" that the RIAA / MPAA has not tampered with my, nor substituted their own P2P application.
Imagine a GPL "trusted" P2P application. You can see the source. You can compile it on a UN-trusted GCC compiler -- but only with very specific compiler options such that it produces the exact trusted binary I have certified.
The P2P app will only connect with a trusted copy of the same application. I can "trust" with the same level of trust that other copies of my P2P app are genuine non-RIAA tampered copies.
(This leaves unaswered the issue of traffic analysis. The IP addresses of the nodes that you end up connecting to. But then, this could be addressed by a swarming-routing protocol like MUTE uses.)
Here's a different argument....
Just like the bad guys can trust my computer against me to ensure closedness (i.e. can't copy / print / save an e-mail), I can similarly trust the bad guys' computers to ensure openness. For instance, I can be assured that my open source can only be processed or manipulated using tools that I trust to keep it open.
My point is that the trust can be used to our benefit. We can "trust" the bad-guys' computers to do our will.
I might want only a limited set of applications accessing a certian storage area.
- P2P application
- XMMS
Then in a different secured storage area, I only want a limited set of applications accessing....- Usenet downloader
- Pr0n Viewer
Since I can trust the software within each group, I know that no evil RIAA people will be accessing my sacred secured storage. (Of course, torture may be allowed in the US -- after all -- think of all the poor record executives.)Imagine a trusted P2P application that will only interconnect with the same trusted application? The trust works both ways. Just like the RIAA thinks they can "trust" their software running my computer to not be of my own creation, or a tampered version of their software, I can "trust" that MY software running on the RIAA's computer is similarly my original code, not tampered with or substituted.
Why crack it?
Q. Why climb a mountain?
A. Because it's there.
Knowing Microsoft it will probably have some security hole that will infect my tv with spyware.
Not until your TV has a cell processor.
Probably not spyware. More likely adware. Each adware will be a "software cell" that runs on a single APU of a cell processor. Because of the way a cell processor works the (software) cells will be able to migrate to other cell processors, such as your PlayStation 3, or other consumer electronics devices.
Microsoft is not a monopoly; you have a choice. You can pay for Microsoft products, or you can not use a computer.
Cable, likewise, is not a monopoly; you have a choice. You can pay your local cable monopoly, or you can not watch television.
Sheesh. What an idiot.
The very things you describe are exactly what defines a monopoly. Buy it from me, or don't buy it at all. That's a monopoly.